Re: combine corrupts insns + dumps with insn cost problems
> But try_combine() doesn't take that into account:
>
> /* If we had to change another insn, make sure it is valid also. */
> if (undobuf.other_insn)
> {
> rtx other_pat = PATTERN (undobuf.other_insn);
> ...
> other_code_number = recog_for_combine (&other_pat,
> undobuf.other_insn, &new_other_notes);
> ...
> PATTERN (undobuf.other_insn) = other_pat;
>
> This is not (necessarily) the same other_pat that we started with.
Right, that's why the code is written indirectly.
> Index: gcc/combine.c
> ===
> --- gcc/combine.c (revision 125984)
> +++ gcc/combine.c (working copy)
> @@ -3298,7 +3298,7 @@ try_combine (rtx i3, rtx i2, rtx i1, int
> return 0;
> }
>
> - PATTERN (undobuf.other_insn) = other_pat;
> + SUBST (PATTERN (undobuf.other_insn), other_pat);
I'm not too thrilled by this. I think that the above code is meant to be the
last verification before committing the change, but is not (anymore?) since
there are 2 calls to undo_all right after it.
Would it solve your problem to move the block of code after the 2 calls?
--
Eric Botcazou
Re: combine corrupts insns + dumps with insn cost problems
On Fri, Jun 29, 2007 at 09:49:26AM +0200, Eric Botcazou wrote:
> > Index: gcc/combine.c
> > ===
> > --- gcc/combine.c (revision 125984)
> > +++ gcc/combine.c (working copy)
> > @@ -3298,7 +3298,7 @@ try_combine (rtx i3, rtx i2, rtx i1, int
> > return 0;
> > }
> >
> > - PATTERN (undobuf.other_insn) = other_pat;
> > + SUBST (PATTERN (undobuf.other_insn), other_pat);
>
> I'm not too thrilled by this. I think that the above code is meant to be the
> last verification before committing the change, but is not (anymore?) since
> there are 2 calls to undo_all right after it.
You're right that the latter two appear to have been added at a later
time.
> Would it solve your problem to move the block of code after the 2 calls?
The following patch also solves the problem, but it makes me feel the
need to state that I've *not* tried to make it look as bad as possible. :-(
Index: gcc/combine.c
===
--- gcc/combine.c (revision 125984)
+++ gcc/combine.c (working copy)
@@ -741,14 +741,17 @@ do_SUBST_MODE (rtx *into, enum machine_m
#define SUBST_MODE(INTO, NEWVAL) do_SUBST_MODE(&(INTO), (NEWVAL))
/* Subroutine of try_combine. Determine whether the combine replacement
- patterns NEWPAT and NEWI2PAT are cheaper according to insn_rtx_cost
- that the original instruction sequence I1, I2 and I3. Note that I1
- and/or NEWI2PAT may be NULL_RTX. This function returns false, if the
- costs of all instructions can be estimated, and the replacements are
- more expensive than the original sequence. */
+ patterns NEWPAT, NEWI2PAT and NEWOTHERPAT are cheaper according to
+ insn_rtx_cost that the original instruction sequence I1, I2, I3 and
+ undobuf.other_insn. Note that I1 and/or NEWI2PAT may be NULL_RTX.
+ NEWOTHERPAT and undobuf.other_insn may also both be NULL_RTX. This
+ function returns false, if the costs of all instructions can be
+ estimated, and the replacements are more expensive than the original
+ sequence. */
static bool
-combine_validate_cost (rtx i1, rtx i2, rtx i3, rtx newpat, rtx newi2pat)
+combine_validate_cost (rtx i1, rtx i2, rtx i3, rtx newpat, rtx newi2pat,
+ rtx newotherpat)
{
int i1_cost, i2_cost, i3_cost;
int new_i2_cost, new_i3_cost;
@@ -789,7 +792,7 @@ combine_validate_cost (rtx i1, rtx i2, r
int old_other_cost, new_other_cost;
old_other_cost = INSN_COST (undobuf.other_insn);
- new_other_cost = insn_rtx_cost (PATTERN (undobuf.other_insn));
+ new_other_cost = insn_rtx_cost (newotherpat);
if (old_other_cost > 0 && new_other_cost > 0)
{
old_cost += old_other_cost;
@@ -2157,6 +2160,8 @@ try_combine (rtx i3, rtx i2, rtx i1, int
int maxreg;
rtx temp;
rtx link;
+ rtx other_pat = 0;
+ rtx new_other_notes;
int i;
/* Exit early if one of the insns involved can't be used for
@@ -3283,12 +3288,9 @@ try_combine (rtx i3, rtx i2, rtx i1, int
/* If we had to change another insn, make sure it is valid also. */
if (undobuf.other_insn)
{
- rtx other_pat = PATTERN (undobuf.other_insn);
- rtx new_other_notes;
- rtx note, next;
-
CLEAR_HARD_REG_SET (newpat_used_regs);
+ other_pat = PATTERN (undobuf.other_insn);
other_code_number = recog_for_combine (&other_pat, undobuf.other_insn,
&new_other_notes);
@@ -3297,23 +3299,6 @@ try_combine (rtx i3, rtx i2, rtx i1, int
undo_all ();
return 0;
}
-
- PATTERN (undobuf.other_insn) = other_pat;
-
- /* If any of the notes in OTHER_INSN were REG_UNUSED, ensure that they
-are still valid. Then add any non-duplicate notes added by
-recog_for_combine. */
- for (note = REG_NOTES (undobuf.other_insn); note; note = next)
- {
- next = XEXP (note, 1);
-
- if (REG_NOTE_KIND (note) == REG_UNUSED
- && ! reg_set_p (XEXP (note, 0), PATTERN (undobuf.other_insn)))
- remove_note (undobuf.other_insn, note);
- }
-
- distribute_notes (new_other_notes, undobuf.other_insn,
- undobuf.other_insn, NULL_RTX, NULL_RTX, NULL_RTX);
}
#ifdef HAVE_cc0
/* If I2 is the CC0 setter and I3 is the CC0 user then check whether
@@ -3331,12 +3316,33 @@ try_combine (rtx i3, rtx i2, rtx i1, int
/* Only allow this combination if insn_rtx_costs reports that the
replacement instructions are cheaper than the originals. */
- if (!combine_validate_cost (i1, i2, i3, newpat, newi2pat))
+ if (!combine_validate_cost (i1, i2, i3, newpat, newi2pat, other_pat))
{
undo_all ();
return 0;
}
+ if (undobuf.other_insn)
+{
+ rtx note, next;
+
+ PATTERN (undobuf.other_insn) = other_pat;
+
+ /* If any of the notes in OTHER_INSN were REG_UNUSED, ensure th
Re: [ARM] Cirrus EP93xx Maverick Crunch Support - CC modes / condexec / CC_REGNUM
On Fri, Jun 29, 2007 at 11:43:49AM +1000, Hasjim Williams wrote: > I guess I will need to define a new "maverick_cc_register". My question > is can I reuse the same CC_REGNUM? Or do I also need another new > CC_REGNUM_MAVERICK pseudo register? See below. > How do I get a new reg number allocated, if I need one? new_hard_regnum = FIRST_PSEUDO_REGISTER ++; [snip] > The only problem would be, is that anything that clobbers CC_REGNUM > needs to clobber CC_REGNUM_MAVERICK too (and vice-versa), since even > though they are pseudo-registers, they both are the NZCV flags in > pc/r15. Exactly. The condition code register is not a pseudo register, it is a hard register and GCC needs to know that a MaverickCrunch comparison will clobber the result of a previous non-MaverickCrunch comparison and vice versa. You must keep the same CC_REGNUM because it's the same NZCV bits in hardware. -- Rask Ingemann Lambertsen
Re: combine corrupts insns + dumps with insn cost problems
>The following patch also solves the problem, but it makes me feel the
> need to state that I've *not* tried to make it look as bad as possible. :-(
I think that your solution is the minimally correct one, so no need for any
form of shyness. ;-)
> @@ -3297,23 +3299,6 @@ try_combine (rtx i3, rtx i2, rtx i1, int
> undo_all ();
> return 0;
> }
> -
> - PATTERN (undobuf.other_insn) = other_pat;
> -
> - /* If any of the notes in OTHER_INSN were REG_UNUSED, ensure that
> they - are still valid. Then add any non-duplicate notes added by
> - recog_for_combine. */
> - for (note = REG_NOTES (undobuf.other_insn); note; note = next)
> - {
> - next = XEXP (note, 1);
> -
> - if (REG_NOTE_KIND (note) == REG_UNUSED
> - && ! reg_set_p (XEXP (note, 0), PATTERN (undobuf.other_insn)))
> - remove_note (undobuf.other_insn, note);
> - }
> -
> - distribute_notes (new_other_notes, undobuf.other_insn,
> - undobuf.other_insn, NULL_RTX, NULL_RTX, NULL_RTX);
> }
> #ifdef HAVE_cc0
>/* If I2 is the CC0 setter and I3 is the CC0 user then check whether
Add the missing line skip before the #ifdef.
> @@ -3331,12 +3316,33 @@ try_combine (rtx i3, rtx i2, rtx i1, int
>
>/* Only allow this combination if insn_rtx_costs reports that the
> replacement instructions are cheaper than the originals. */
> - if (!combine_validate_cost (i1, i2, i3, newpat, newi2pat))
> + if (!combine_validate_cost (i1, i2, i3, newpat, newi2pat, other_pat))
> {
>undo_all ();
>return 0;
> }
>
> + if (undobuf.other_insn)
> +{
> + rtx note, next;
> +
> + PATTERN (undobuf.other_insn) = other_pat;
> +
> + /* If any of the notes in OTHER_INSN were REG_UNUSED, ensure that
> they + are still valid. Then add any non-duplicate notes added by
> + recog_for_combine. */
> + for (note = REG_NOTES (undobuf.other_insn); note; note = next)
> + {
> + next = XEXP (note, 1);
> +
> + if (REG_NOTE_KIND (note) == REG_UNUSED
> + && ! reg_set_p (XEXP (note, 0), PATTERN (undobuf.other_insn)))
> + remove_note (undobuf.other_insn, note);
> + }
> +
> + distribute_notes (new_other_notes, undobuf.other_insn,
> + undobuf.other_insn, NULL_RTX, NULL_RTX, NULL_RTX);
> +}
>/* We now know that we can do this combination. Merge the insns and
> update the status of registers and LOG_LINKS. */
And put the new block just after the above comment, surrounded by a couple of
line skips.
>If I'm going to say something I like about this version of the patch,
> then it'll be that we don't mung the notes until we've checked the costs.
Right, I also think that this is a progress.
The patch is pre-approved for mainline with the 2 aforementioned changes.
--
Eric Botcazou
Re: PTR-PLUS merge into the mainline
Hi,
On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote:
> Roman Zippel <[EMAIL PROTECTED]> wrote on 06/28/2007 07:54:43 PM:
>
> > Hi,
> > Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
> > the other cases. While I tried to debug this I narrowed it down to the
> > changes in fold_binary(), but I don't really know how to fix this, so
> > I could use some help here.
>
> The main thing is that this is really PR 32120. The problem is only
> related to the
> merge because of the way fold_binary works.
I'm not sure that's related, what's happening in my example is that the
call to fold_plusminus_mult_expr() defeats the optimization attempted in
pointer_int_sum(). If I use the patch below to restrict the condition, my
problem is fixed, but PR32120 is unchanged.
Actually if I compare the final_cleanup dump of PR32120 with the output
from gcc 4.1, they are basically identical.
bye, Roman
---
gcc/fold-const.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -9173,8 +9173,8 @@ fold_binary (enum tree_code code, tree t
/* Handle (A1 * C1) + (A2 * C2) with A1, A2 or C1, C2 being the
same or one. */
- if ((TREE_CODE (arg0) == MULT_EXPR
- || TREE_CODE (arg1) == MULT_EXPR)
+ if (TREE_CODE (arg0) == MULT_EXPR
+ && TREE_CODE (arg1) == MULT_EXPR
&& (!FLOAT_TYPE_P (type) || flag_unsafe_math_optimizations))
{
tree tem = fold_plusminus_mult_expr (code, type, arg0, arg1);
Re: Does unrolling prevents doloop optimizations?
Hello,
> We did just this change
> (on top of SMS patches we intend to send in the next
> couple of weeks) and it did helped a lot - we succeeded on all unrolled
> loops that could not be SMSed before. Do you think it is safe to remove this
> check? There was no regressions found in our testing. For note, we did our
> work on gcc 4.1 based branch.
what change? Could you please send me the patch? If you mean just
removing the check in doloop_condition_get, that is definitely wrong and
cannot change anything (at least on mainline, I am not sure about 4.1
branch -- but anyway, you cannot submit new changes for 4.1).
Zdenek
> Thanks,
> Vladimir
>
> On 6/12/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> >
> >Hello,
> >
> >> To make sure I understood you correctly, does it mean that the change
> >> (below in /* */) in doloop_condition_get is safe?
> >>
> >> /* We expect a GE or NE comparison with 0 or 1. */
> >> if (/*(GET_CODE (condition) != GE
> >> && GET_CODE (condition) != NE)
> >> ||*/ (XEXP (condition, 1) != const0_rtx
> >> && XEXP (condition, 1) != const1_rtx))
> >>return 0;
> >
> >no; that there is nothing wrong with doloop_condition_get --
> >changing it will not help, as it is not applied to the
> >exit condition of the loop at all. The problem must be somewhere
> >else.
> >
> >Zdenek
> >
> >> Thanks,
> >> Vladimir
> >>
> >>
> >> On 6/12/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> >> >Hello,
> >> >
> >> >> In file loop_doloop.c function doloop_condition_get makes sure that
> >> >> the condition is GE or NE
> >> >> otherwise it prevents doloop optimizations. This caused a problem for
> >> >> a loop which had NE condition without unrolling and EQ if unrolling
> >> >> was run.
> >> >
> >> >actually, doloop_condition_get is not applied to the code of the
> >> >program, so this change is irrelevant (doloop_condition_get is applied
> >> >to the doloop pattern from the machine description). So there must be
> >> >some other reason why doloop transformation is not applied for your
> >> >loop.
> >> >
> >> >Zdenek
> >> >
> >> >> Can I make doloop work after the unroller?
> >> >>
> >> >> Thanks,
> >> >> Vladimir
> >> >>
> >> >>
> >>
> >>
> >> >> Without unrolling:
> >> >> (insn 135 80 136 4 (set (reg:SI 204 [ LastIndex ])
> >> >>(plus:SI (reg:SI 204 [ LastIndex ])
> >> >>(const_int -1 [0x]))) 51 {addsi3} (nil)
> >> >>(nil))
> >> >>
> >> >> (jump_insn 136 135 84 4 (set (pc)
> >> >>(if_then_else (ne:SI (reg:SI 204 [ LastIndex ])
> >> >>(const_int 0 [0x0]))
> >> >>(label_ref:SI 69)
> >> >>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 135
> >(nil))
> >> >>(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
> >> >>(nil)))
> >> >>
> >> >>
> >> >> After unrolling:
> >> >> (insn 445 421 446 21 (set (reg:SI 213)
> >> >>(plus:SI (reg:SI 213)
> >> >>(const_int -1 [0x]))) 51 {addsi3} (nil)
> >> >>(nil))
> >> >>
> >> >> (jump_insn 446 445 667 21 (set (pc)
> >> >>(if_then_else (eq:SI (reg:SI 213)
> >> >>(const_int 0 [0x0]))
> >> >>(label_ref:SI 465)
> >> >>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 445
> >(nil))
> >> >>(expr_list:REG_BR_PROB (const_int 1000 [0x3e8])
> >> >>(nil)))
> >> >
> >
Some numbers on Regressions
Hello, here are the numbers of regressions in 4.3 and the new regressions only in 4.3: Date All regressions new regressions 16.6.: 343 93 17.6.: 346 96 18.6.: 337 87 19.6.: 336 87 20.6.: 338 89 22.6.: 341 92 23.6.: 339 90 24.6.: 339 91 25.6.: 335 87 26.6.: 335 86 28.6.: 338 87 29.6.: 338 87 Many Greets Andreas Meier
Question about validity of wfmath template code
After analyzing a build failure of wfmath with gcc-4.2, I condensed the issue
it was having to the following test case:
template class A { public: T x1; U x2; };
template class container_with_x1>
int f(const container_with_x1& y) {
return y.x1;
}
int g() {
A y;
return f(y);
}
This code compiles with g++-4.1, but fails with g++-4.2 and the snapshot of
g++-4.3 currently in Debian's gcc-snapshot package. My question is: is this
valid code or not?
--
Daniel Schepler
Re: Type-punning
> I'll try to make a simple example on which GCC produces bad code.
You can find an example below. GCC-4.1 generates bad code (GCC-4.2 is
fine). Neither version give a type-punning warning, though. I'm sorry
that I didn't check gcc-4.2 before I started this thread.
Geza
Here's the code, I couldn't simplify it further to still have bad code
with gcc-4.1.
gcc version: 4.1.3 20070601 (prerelease) (Debian 4.1.2-12)
#include
class Tuple {
public:
union {
int c[2];
struct {
int x, y;
};
};
public:
Tuple() { }
Tuple(int x, int y) : x(x), y(y) { }
};
class Vector;
class Point: public Tuple {
public:
Point() { }
Point(int x, int y) : Tuple(x, y) { }
inline Vector operator-(const Point &other) const;
};
class Vector: public Tuple {
public:
Vector() { }
Vector(int x, int y) : Tuple(x, y) { }
Point &asPoint() {
return reinterpret_cast(*this);
}
Point toPoint() const {
return Point(x, y);
}
};
Vector Point::operator-(const Point &other) const {
return Vector(x-other.x, y-other.y);
}
inline bool foo(int x, Point a) {
if (a.x<=x) { return false; }
return true;
}
int main() {
Point a;
a.x = 1;
a.y = 2;
time(0);
int n = 0;
for (int y=0; y<=44; y++) {
if (foo(3, (a-a).asPoint())) {
n++;
}
}
return n;
}
Re: Status of trunk freeze
Steve Kargl wrote: > What's the status of the trunk freeze for going from stage > 1 to stage 2? AFAICT, the number of regression on trunk > has increased since you sent > > http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html The important question is whether that change reflects more bugs being introduced or just more bugs being found. I think it's the latter, in which case that doesn't indicate that quality is getting worse. > There have been a number of commits to trunk that do not > address regressions. That's disappointing, if true. My previous message was pretty clear on this point: > Other then the merges mentioned > above, and documentation improvements, the only patches that should be > committed during the lockdown are fixes for regressions. I do think that attention to quality is something that we need to improve. People who are contributing fixes for regressions are doing something which is just as important as people who are contributing new optimizations. I will be sending out a status report shortly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-06-29)
We have spent the last two weeks in lockdown, hopefully fixing regressions. At this point, there are 153 P3 and higher regressions open against GCC 4.3.0. In reviewing those, I was struck by how many are in fact new regressions in 4.3 -- problems that did not occur in previous releases. These include a number of P1 problems such as: * Failure to bootstrap on relatively common platforms (e.g., PR32540) * Failure to correctly compile SPEC benchmarks (e.g., PR32303) * ICEs on various applications See the full list here: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= It's clear that the dataflow and PTR_PLUS changes, while of course beneficial, have (as we all expected) caused a bit of collateral fallout. I think it's very important that we step up to fix these problems now, while fresh in our minds. That said, I think it's time to enter Stage 2. So, effective immediately, the lockdown is over. As stated previously, I intend to reenter the lockdown mode every so often, in order to help us focus on closing regressions. Danny, I would still appreciate your help in setting up additional fields in Bugzilla that we can use to help make people aware of regresions that they have caused Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: PTR-PLUS merge into the mainline
On 6/29/07, Roman Zippel <[EMAIL PROTECTED]> wrote: Hi, On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote: > Roman Zippel <[EMAIL PROTECTED]> wrote on 06/28/2007 07:54:43 PM: > > > Hi, > > Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with > > the other cases. While I tried to debug this I narrowed it down to the > > changes in fold_binary(), but I don't really know how to fix this, so > > I could use some help here. > > The main thing is that this is really PR 32120. The problem is only > related to the > merge because of the way fold_binary works. I'm not sure that's related, what's happening in my example is that the call to fold_plusminus_mult_expr() defeats the optimization attempted in pointer_int_sum(). If I use the patch below to restrict the condition, my problem is fixed, but PR32120 is unchanged. Actually if I compare the final_cleanup dump of PR32120 with the output from gcc 4.1, they are basically identical. The code to fold_binary was added by: r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9 lines 2005-11-19 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/23294 * fold-const.c (fold_plusminus_mult_expr): New function. (fold_binary): Use to canonicalize PLUS_EXPR and MINUS_EXPR cases, remove now unnecessary code. * gcc.dg/tree-ssa/pr23294.c: New testcase. And it looks like it was doing this transformation this way on purpose. Now as I mentioned before the way this should be done is using PRE/FRE to catch the redudent multiplication. -- Pinski
failed to compile trunk svn rev 126124
Is it just me, or not?
On my system (Debian/Sid/AMD64 with gcc = 4.1.2 from Debian)
.
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/usr/src/Lang/gcc-trunk/_Obj/build-x86_64-unknown-linux-gnu/fixincludes'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
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/usr/src/Lang/gcc-trunk/gcc
-I/usr/src/Lang/gcc-trunk/gcc/. -I/usr/src/Lang/gcc-trunk/gcc/../include -I/usr/src/Lang/gcc-trunk/gcc/../libcpp/include
-I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber -I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
/usr/src/Lang/gcc-trunk/gcc/cse.c -o cse.o
/usr/src/Lang/gcc-trunk/gcc/cse.c:7015: error: 'TODO_verify_rtl_sharing'
undeclared here (not in a function)
make[3]: *** [cse.o] Error 1
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make: *** [all] Error 2
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h
Seongbae Park (박성배, 朴成培) wrote: > Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed, > dataflow doesn't see any definition of the return address register, > and happily treats b0 as not live throughout the function body. > Then, global allocator, guided by this information, allocates > b0 for something else - leading to the return address corruption. The problem here is that defining INCOMING_RETURN_ADDR_RTX automatically enables the DWARF2_UNWIND_INFO support. See defaults.h which does: /* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that the rest of the DWARF 2 frame unwind support is also provided. */ #if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX) #define DWARF2_UNWIND_INFO 1 #endif The DWARF2_UNWIND_INFO support happens not to work on IA-64 for various reasons. This doesn't matter, as IA-64 has its own unwind info format that we use instead of the DWARF2 info, as required by the ABI. Emitting DWARF2 unwind info would just bloat the object files unnecessarily. Since we didn't need INCOMING_RETURN_ADDR_RTX for other reasons, and because we don't want gcc to emit the DWARF2 unwind info, the simple solution was just to not define INCOMING_RETURN_ADDR_RTX. Since the dataflow stuff now needs INCOMING_RETURN_ADDR_RTX, I think the right solution is to uncouple DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX so that we can have the latter without the former. The first easy step is to put #define DWARF2_UNWIND_INFO 0 in the config/ia64/ia64.h file. The second harder step is to fix everyplace in the compiler that uses DWARF2_UNWIND_INFO to check its value instead of just checking to see if it is defined. So for instance, in final.c, instead of #if defined (DWARF2_UNWIND_INFO) if (dwarf2out_do_frame ()) dwarf2out_frame_debug (insn, false); #endif we would have #if defined (DWARF2_UNWIND_INFO) if (DWARF2_UNWIND_INFO && dwarf2out_do_frame ()) dwarf2out_frame_debug (insn, false); #endif or something like that. There are some things we can't avoid though. There are a lot of functions in dwarf2out.c that get included in cc1 when DWARF2_UNWIND_INFO is defined, and these will now be included in the IA-64 cc1 even though they will never be called, which is unfortunate. An alternative solution would be to delete the 3 lines of code in defaults.h that set DWARF2_UNWIND_INFO when INCOMING_RETURN_ADDR_RTX is defined, then add a definition of DWARF2_UNWIND_INFO to all targets that need it. This is a better solution from an IA-64 point of view, since it presents us from defining a lot of functions we don't need or want. Unfortunately, finding and fixing all target header files that now need to define DWARF2_UNWIND_INFO will be error prone. Unless maybe we just assume that all targets except IA-64 should define it, which is easy enough. I would not be able to test such a patch though, as I do not have access to all targets that would be modified. Yet another solution would be to add another macro INCOMING_RETURN_ADDR_RTX_2 which acts like INCOMING_RETURN_ADDR_RTX, except that it doesn't enable the unwanted and undesirable DWARF2_UNWIND_INFO as a side-effect. Not very elegant, but it would be a simpler change. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: failed to compile trunk svn rev 126124
Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127.
2007/6/29, Basile STARYNKEVITCH <[EMAIL PROTECTED]>:
Is it just me, or not?
On my system (Debian/Sid/AMD64 with gcc = 4.1.2 from Debian)
.
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/usr/src/Lang/gcc-trunk/_Obj/build-x86_64-unknown-linux-gnu/fixincludes'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
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/usr/src/Lang/gcc-trunk/gcc
-I/usr/src/Lang/gcc-trunk/gcc/. -I/usr/src/Lang/gcc-trunk/gcc/../include
-I/usr/src/Lang/gcc-trunk/gcc/../libcpp/include
-I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber
-I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
/usr/src/Lang/gcc-trunk/gcc/cse.c -o cse.o
/usr/src/Lang/gcc-trunk/gcc/cse.c:7015: error: 'TODO_verify_rtl_sharing'
undeclared here (not in a function)
make[3]: *** [cse.o] Error 1
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make: *** [all] Error 2
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Question about validity of wfmath template code
On Friday 29 June 2007 17:31:17 pm Lawrence Crowl wrote: > I've sent your question to the C++ committee, as I wasn't > sure of the answer. It's been pointed out to me, after I asked this, that the example code from the second bullet under C++ for the gcc-4.2 changes document is almost identical, and the general description seems to indicate this change was intentional. -- Daniel Schepler
gcc-4.3-20070629 is now available
Snapshot gcc-4.3-20070629 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070629/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 126129 You'll find: gcc-4.3-20070629.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070629.tar.bz2 C front end and core compiler gcc-ada-4.3-20070629.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070629.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070629.tar.bz2 C++ front end and runtime gcc-java-4.3-20070629.tar.bz2 Java front end and runtime gcc-objc-4.3-20070629.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070629.tar.bz2The GCC testsuite Diffs from 4.3-20070622 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: failed to compile trunk svn rev 126124
> Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127. This was caused by accidental commit of mine (ie I've commited cse.c with sharing changes). It is reverted now. Honza
Re: Does unrolling prevents doloop optimizations?
Hello, > By "this change" I mean just commenting out the check in > doloop_condition_get. After applying the patch that introduced DOLOOP > patterns for SPU (http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01470.html) > we needed this hack in order to be able to use the doloop_condition_get to > return the register decremented by the branch instruction for any unrolled > loop (The unroller changed originally GE loops to EQ ). Where can this check > be required? Note that we did not touched the similar check in > doloop_modify. We tested this on our SPU branch and saw no regressions. hmmm I see now that modulo-sched.c:doloop_register_get uses doloop_condition_get, which is why this may affect something. Anyway, changing doloop_condition_get is wrong. Just teach modulo-sched to use number of iterations analysis from loop-iv.c instead of the doloop_register_get hack, Zdenek
