Re: Problems with compiling svn trunk [libdecnumber]
You are compiling in the source directory which is not a well supported way of compiling GCC. Yeah, but I wasn't and still ran into that (or similar) problem. :) Anyway, this patch solves it: Index: libgcc/configure.ac === --- libgcc/configure.ac(revision 124612) +++ libgcc/configure.ac(working copy) @@ -100,6 +100,7 @@ GCC_NO_EXECUTABLES AC_PROG_CC AC_PROG_CPP_WERROR +GCC_HEADER_STDINT(gstdint.h) + # Check for decimal float support. On the other hand, it looks to me that there is a more deep problem, in that we were trying to use host include files to compile a target library. I don't have time to investigate it now, though. If a libdecnumber folk wants to comment here, [s]he's more than welcome. I am not committing this until Monday. Paolo
TroubleAgent.de
...der Profi in Sachen Beziehungsmanagement! Die TroubleAgentur ist ein Dienstleister bestehend aus freiberuflichen Beratern, der den Menschen helfen soll, sich in verschiedenen Lebensphasen, wie z.B.: Partnersuche, Familiengründung, Trennung, Tod, oder Einsamkeit zurecht zufinden. Es fällt vielen Menschen zunehmend schwerer, sich den unangenehmen Lebenssituationen zu stellen, oder sich in diesen zu recht zu finden, oder Sie haben einfach nur Angst unangenehme Nachrichten zu übermitteln. Wir, helfen Ihnen, wenn Ihre Beziehung nicht mehr richtig funktioniert - ...wenn gar nichts mehr geht! Wir, helfen auch Beziehungen zu retten - ... durch Professionelles Krisenmanagement! Wir, geben gerne bei neuen Beziehungen Hilfestellung. Wir, bieten für jeden das richtige Paket - und wenn nicht passen wir Ihnen eins an! Wir, geben, oder prüfen ein Alibi - Ist Ihr Partner/in treu? Besuchen Sie uns unter: http://www.TroubleAgent.de Mit freundlichen Grüßen Das Team von TroubleAgent.de
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
On 5/17/07, Eric Christopher <[EMAIL PROTECTED]> wrote: On May 16, 2007, at 8:00 PM, Jack Howarth wrote: >Currently gcc 4.2.0 suffers from 90 libjava failures on i686- > apple-darwin8 > including the boehm gctest. Backporting the changes from revision > 120684... > > http://gcc.gnu.org/viewcvs?view=rev&revision=120684 > > as suggested in... > > > which includes one new failure (Process_5). Shouldn''t the changes in > revision 120684 be backported to gcc 4.2.1? Also does anyone know > if additional fixes to eliminate these remaining failures currently > reside in gcc trunk? Thanks in advance. Sure, seems reasonable. Introducing a regression on the branch doesn't sound reasonable. Also are those regressions? Or is the patch referenced strictly specifc to Darwin? Richard.
gcc-4.2 manuals: GNU OpenMP Manual?
Should section "GCC 4.2.0 manuals" of http://gcc.gnu.org/onlinedocs/ not also list the "GNU OpenMP Manual" that is available for 4.2? Thanks Daniel
RE: gcc-4.2 manuals: GNU OpenMP Manual?
On 17 May 2007 12:18, Daniel Franke wrote: > Should section "GCC 4.2.0 manuals" of > > http://gcc.gnu.org/onlinedocs/ > > not also list the "GNU OpenMP Manual" that is available for 4.2? > Yes, it probably should. The released docs have been prepared correctly: http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp is live. It should probably also point to the libstdc++ docs as well, but I guess there aren't versioned sets of online docs available for that. cheers, DaveK -- Can't think of a witty .sigline today
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
Richard, A test build of r120684 applied to gcc 4.2.0 on powerpc-apple-darwin8 doesn't show the same Process_5 failure but rather a single Process_1 failure. Interestingly all the Thread_Sleep_2 failures I normally see disappeared. Hopefully some of the libjava developers can shed some light on the Process_# failures (perhaps we need to backport additional patches from gcc trunk). Jack ps I'll do a build on i386 and x86_64 linux to see if the Process_# regressions are Darwin specific. On Thu, May 17, 2007 at 10:51:58AM +0200, Richard Guenther wrote: > > Introducing a regression on the branch doesn't sound reasonable. Also > are those regressions? Or is the patch referenced strictly specifc to > Darwin? > > Richard.
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
Doh! Perhaps I need to add this as well (which went into four days after r120684... 2007-01-15 Andreas Tobler <[EMAIL PROTECTED]> * os_dep.c (defined(MPROTECT_VDB) && defined(DARWIN)): Adjust mail reference. (catch_exception_raise): Fix typo in the I386 exc_state. I'll test backporting that in addition to r120684 tonight. Jack
Re: Problems with compiling svn trunk [libdecnumber]
> >>You are compiling in the source directory which is not a well > >>supported way of compiling GCC. To confirm this theory - yes, make completed with most targets when built from a different directory than the source directory. I should have read the latest install instructions carefully. On Thu, May 17, 2007 at 09:20:55AM +0200, Paolo Bonzini wrote: > >Yeah, but I wasn't and still ran into that (or similar) problem. :) > Anyway, this patch solves it: Thanks for the patch. Unfortunately, due my unfamiliarity with GCC (or my incompetence? :-) ), I don't know how to re-generate libgcc/configure from the alterred libgcc/configure.ac. I checked the install instructions and couldn't find a reference to this. I tried both autoconf and automake. Neither did the 'right' thing. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
It also looks like we need... r120874 | mrs | 2007-01-17 15:12:51 -0500 (Wed, 17 Jan 2007) | 2 lines * os_dep.c: Fix i686-apple-darwin9 builds. in addition to r120801 for r120684 to work. I am also unclear if I should be regenerating include/gc_config.h.in as well as was done in r120853. Hopefully these will suppress the Process_# regressions introduced in gcc 4.2.0 witrh the r120684 backport. Jack
Re: trimming excess errors from -Werror
And also error when I add "-g" Excellent, thanks for the feedback. I believe that the modified configure test will solve this issue, and will be monitoring gcc-testresults for confirmation. best, benjamin
Re: backport of Revision 120684 for Macintel into gcc 4.2.1?
Jack Howarth wrote: Doh! Perhaps I need to add this as well (which went into four days after r120684... 2007-01-15 Andreas Tobler <[EMAIL PROTECTED]> * os_dep.c (defined(MPROTECT_VDB) && defined(DARWIN)): Adjust mail reference. (catch_exception_raise): Fix typo in the I386 exc_state. I'll test backporting that in addition to r120684 tonight. Jack I have backported r120684, 120801, 120853, 120874, 120977 and I do not see any failure on Process_#. I have the same failures as you have (except Process_#). The Throw_2 is due to missing signal handling stuff in gcc and libjava. The others I did not investigate. I gave up testing libjava on i?86-darwin since I lack a working ld64 These are the results: === libjava Summary === # of expected passes6962 # of unexpected failures26 # of expected failures 12 # of untested testcases 26 Andreas
I don't understand some of gcc-4.1-20070514
I suppose that there are some bugs in the snapshot gcc-4.1-20070514.
gcc/rtl.h
-
/* Register Transfer Language EXPRESSIONS CODE CLASSES */
enum rtx_class {
/* We check bit 0-1 of some rtx class codes in the predicates below. */
/* Bit 0 = comparison if 0, arithmetic is 1 #<-wrong! v- bit 0
Bit 1 = 1 if commutative. */#<-wrong! v- bit 1
RTX_COMPARE, /* 0 */ # 0 = 0 0 0 0
RTX_COMM_COMPARE, # 1 = 0 0 0 1
RTX_BIN_ARITH, # 2 = 0 0 1 0
RTX_COMM_ARITH, # 3 = 0 0 1 1
/* Must follow the four preceding values. */
RTX_UNARY, /* 4 */ # 4 = 0 1 0 0
RTX_EXTRA, # 5 = 0 1 0 1
RTX_MATCH, # 6 = 0 1 1 0
RTX_INSN, # 7 = 0 1 1 1
/* Bit 0 = 1 if constant. */
RTX_OBJ, /* 8 */ # 8 = 1 0 0 0
RTX_CONST_OBJ, # 9 = 1 0 0 1
RTX_TERNARY,# 10= 1 0 1 0
RTX_BITFIELD_OPS, # 11= 1 0 1 1
RTX_AUTOINC # 12= 1 1 0 0
};
#
# BEGIN CORRECTING below will be correct!
#
/* We check bit 0-1 of 4 first rtx class codes in the predicates below.
Bit 0 = 1 if commutative.
Bit 1 = 0 if comparison, 1 if arithmetic. */
#
# END CORRECTING
#
gcc/loop.c
--
#
# To see who uses loop_invariant_p that doesn't return a boolean,
#returns an int with values 0, 1 and 2.
#
# Be careful with it when you will really assume inside of the action's body
# of IF because it's 1 or 2 (or it's !0), and when wont really because it is
# 0 (or it's !1 and !2).
# It has to distinguish easyly if
# IT REALLY IS :
# =0 : "NOT INVARIANT" OF THE LOOP !!!
# =1 : "INVARIANT INCONDITIONAL" OF THE LOOP !!!
# =2 : "INVARIANT CONDITIONAL" OF THE LOOP !!!
# Some lines put condition ([XXX =] loop_invariant_p) and another lines
# put the equivalent condition (([XXX =] loop_invariant_p) != 0), and
# i don't understand the why of this difference?
# Actually, in the src code, it's confuse.
# a) tem = loop_invariant_p (...)
# What meaning is it when you think in the algorithm?
# * Does it mean that it can be "INVARIANT INCOND." or "INVARIANT COND."?
# * Or, does it mean that it's "INVARIANT INCOND." but not "INVARIANT COND."?
# b) (... && loop_invariant_p (...))
# Does you think that it will be true because (... && true')?
# * Does it mean that it will be true' because it was
# "INVARIANT INCOND."(=1) or "INVARIANT COND."(=2)?
# * Or only "INVARIANT INCOND."(=1) because true' is 1 and
# "INVARIANT COND."(=2) doesn't count?
# c) if (!loop_invariant_p (loop, iv->add_val))
# "! NOT INVARIANT" is true "INVARIANT" because not(not(x))=x, but
# "INVARIANT COND." only or "INVARIANT INCOND." only or either?
# d) (... || ! loop_invariant_p (...) || loop_invariant_p (...))
# I see it a little dangerous. || is applied to bools, but they are ints.
# Is it "|| beetween bools casted from ints" or "| beetween ints"?
#
# BEGIN CORRECTING PROPOSAL (it will reduce the confusion)
#
To define the predicates
IS_NOT_INVARIANT_OF_LOOP_P (...)
IS_INVARIANT_INCONDITIONAL_OF_LOOP_P (...)
IS_INVARIANT_CONDITIONAL_OF_LOOP_P (...)
IS_NOT_INVARIANT__OR_INVARIANT_INCONDITIONAL_OF_LOOP_P (...)
IS_NOT_INVARIANT__OR_INVARIANT_CONDITIONAL_OF_LOOP_P (...)
IS_INVARIANT_INCONDITIONAL_OR_CONDITIONAL_OF_LOOP_P (...)
note: i don't recommend to use ! with them (except some very rare situations).
(it's complete, good completeness, understandable like natural language)
#
# END CORRECTING PROPOSAL
#
/* Like rtx_equal_p, but attempts to swap commutative operands. This is
important to get some addresses combined. Later more sophisticated
transformations can be added when necessary.
??? Same trick with swapping operand is done at several other places.
It can be nice to develop some common way to handle this. */
static int
rtx_equal_for_prefetch_p (rtx x, rtx y)
{
...
if (COMMUTATIVE_ARITH_P (x))
{
return ((rtx_equal_for_prefetch_p (XEXP (x, 0), XEXP (y, 0))
&& rtx_equal_for_prefetch_p (XEXP (x, 1), XEXP (y, 1)))
|| (rtx_equal_for_prefetch_p (XEXP (x, 0), XEXP (y, 1))
&& rtx_equal_for_prefetch_p (XEXP (x, 1), XEXP (y, 0;
}
...
}
Why not i can add
if (COMMUTATIVE_ARITH_P (x) || COMMUTATIVE_COMPARE_P (x) || ...) ?
Or will it be a problem in the order of the execution like
the aliasing can affect them,..?
Remember, the binary operators
'+', '*', '==', '!=', '&', '|', '^', ('&&' and '||' are exception) ...
are mathematically commutative. ('-', '/', '%' are not)
a + b <=> b + a a & b <=> b & a
a * b <=> b * a a | b <=> b | a
a == b <=> b == a a ^ b <=> b ^ a
Re: I don't understand some of gcc-4.1-20070514
> I suppose that there are some bugs in the snapshot gcc-4.1-20070514. Dozens, literally, just browse the bug database. If you want to help, pick one of them and try to fix it. -- Eric Botcazou
Re: I don't understand some of gcc-4.1-20070514
2007/5/18, Eric Botcazou <[EMAIL PROTECTED]> wrote: > I suppose that there are some bugs in the snapshot gcc-4.1-20070514. Dozens, literally, just browse the bug database. If you want to help, pick one of them and try to fix it. -- Eric Botcazou How? I can not browse http://gcc.gnu.org/bugzilla/ because has not the 'browse' button.
Re: I don't understand some of gcc-4.1-20070514
> > Dozens, literally, just browse the bug database. If you want to help, pick > > one of them and try to fix it. > > > How? > I can not browse http://gcc.gnu.org/bugzilla/ because has not the > 'browse' button. Ah, the joys of bugzilla. For 4.1 issues, you can go to GCC's front page and under Previous Release Series 4.1.2, click on Serious Regressions for a list (which is a bookmarked search). A bookmark to new reports over the past 7 days can be found: http://gcc.gnu.org/bugzilla/weekly-bug-summary.cgi which is "Weekly bug summary" from http://gcc.gnu.org/bugzilla/report.cgi With a bugzilla account, you can save searches, e.g.: http://gcc.gnu.org/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=4.1%20%5C%204.0%20regressions (from my saved searches) is a list of regressions in 4.1 NOT present in 4.0. >From any bug-list-summary such as the above, you can click "Edit Search" for tweak an existing search as a starting point. Try finding all new bug reports opened in the last 21 days, or regressions in 4.2 that are not in 4.1 from the above examples and try more elaborate searches. I suggest playing around with the search interface until you're comfortable. Happy bug hunting! Fang
Re: I don't understand some of gcc-4.1-20070514
> I can not browse http://gcc.gnu.org/bugzilla/ because has not the > 'browse' button. Well, your favorite browser very likely hasn't got one either and yet you can browse the Internet, so there must be a similar way with Bugzilla... Hint: look for a button called 'Search'. -- Eric Botcazou
