This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.3 branch] IA64 bootstrap failure


"H. J. Lu" <hjl@lucon.org> writes:

> I found:
>
> /* If we don't have __builtin_constant_p, or it's not acceptable in
>    array initializers, fall back to assuming that all conditions
>    potentially vary at run time.  It works in 3.0.1 and later; 3.0
>    only when not optimizing.  */
> #if (GCC_VERSION >= 3001) || ((GCC_VERSION == 3000) && !__OPTIMIZE__)
> # define MAYBE_EVAL(expr) (__builtin_constant_p(expr) ? (int) (expr) : -1)
> #else
> # define MAYBE_EVAL(expr) -1
> #endif
>
> in the generated insn-conditions.c. It means the stage1 compiler may
> be different from the stage2 compiler, depending on what compiler is
> used to bootstrap gcc. I think insn-conditions.c should be the same
> regardless the compiler used to boostrap.

Don't be ridiculous.  The stage1 compiler is never going to be
identical to the stage2 compiler.  Ignoring for the moment the
fact that stage1 is compiled with some random preexisting compiler
with all optimizations off, there is a similar chunk of logic in the
tree and RTL checking macros, which potentially affects every file in
GCC.

You are looking in the wrong place.  The observed difference is a
register allocation choice; why aren't you looking at the register
allocator?

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]