Re: gcc bootstrap broken on i686-linux-gnu

Re: gcc bootstrap broken on i686-linux-gnu

[John David Anglin]

> Certainly.  Sorry for any inconvenience.  The two possible
> changes in behaviour are that -1.0*x is now tranformed into
> -x by default (this previously only happened with -ffast-math),

This transformation is going to cause a problem on hppa1* machines
because prior to PA2.0 the HP IEEE implementation didn't have a 
fneg instruction.  So, to get correct behavior we convert -x to
-1.0*x (see for example negsf2 pattern in pa.md) except when
flag_unsafe_math_optimizations is set where we use fsub.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc bootstrap broken on i686-linux-gnu

[Roger Sayle]

Hi Dave,
> > Certainly.  Sorry for any inconvenience.  The two possible
> > changes in behaviour are that -1.0*x is now tranformed into
> > -x by default (this previously only happened with -ffast-math),
>
> This transformation is going to cause a problem on hppa1* machines
> because prior to PA2.0 the HP IEEE implementation didn't have a
> fneg instruction.  So, to get correct behavior we convert -x to
> -1.0*x (see for example negsf2 pattern in pa.md) except when
> flag_unsafe_math_optimizations is set where we use fsub.

Fortunately, the -1.0*x into x transformation is being applied in
fold-const.c, so works on the tree representation of the expression.
This should be completely safe, and allows things like
"x = (y<0)? -1.0*y : y" to be recognized as "x = fabs(y)".
If the "-y" survives until RTL generation time, the PA backend will
convert it back into the multiplication.

I agree there could be an issue if this transformation were to be
added to the RTL optimizers.

Roger
--

gcc bootstrap broken on i686-linux-gnu

[Andreas Jaeger]

I do build gcc with --enable-checking=misc,tree,rtl,gc,rtlflag on
i686-linux-gnu and it fails currently building libjava:



/builds/gcc/gcc/xgcc -shared-libgcc -B/builds/gcc/gcc/ -nostdinc++ -L/builds/gcc/i686-pc-linux-gnu/libstdc++-v3/src -L/builds/gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/opt/gcc/3.3-devel/i686-pc-linux-gnu/bin/ -B/opt/gcc/3.3-devel/i686-pc-linux-gnu/lib/ -isystem /opt/gcc/3.3-devel/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. -I/cvs/gcc/libjava -I./include -I./gcj -I/cvs/gcc/libjava -Iinclude -I/cvs/gcc/libjava/include -I/cvs/gcc/libjava/../boehm-gc/include -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I/cvs/gcc/libjava/libltdl -I/cvs/gcc/libjava/libltdl -I/cvs/gcc/libjava/.././libjava/../gcc -I/cvs/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D__NO_MATH_INLINES -ffloat-store -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gcc/3.3-devel\" -g -O2 -D_GNU_SOURCE -Wp,-MD,.deps/verify.pp -c /cvs/gcc/libjava/verify.cc  -fPIC -DPIC -o .libs/verify.o
/cvs/gcc/libjava/verify.cc: In function `void debug_print(const char*, ...)':
/cvs/gcc/libjava/verify.cc:40: warning: unused parameter `const char*fmt'
/cvs/gcc/libjava/interpret.cc: In member function `void 
   _Jv_InterpMethod::run(void*, ffi_raw*)':
/cvs/gcc/libjava/interpret.cc:3170: internal compiler error: RTL check: 
   expected code `reg', have `subreg' in split_2, at insn-recog.c:61241
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

I nailed it down to this patch.  Bootstrapping with that patch applied
causes the ICE, without it everything seems to be fine.

Roger, can you investigate, please?

I don't understand how your patch can cause this problem but it seems
to be the case here.

+2002-07-27  Roger Sayle  <roger@eyesopen.com>
+
+       * Makefile.in: rtlanal.o now depends upon real.h.
+
+       * flags.h [flag_signaling_nans]: New flag.
+       [HONOR_SNANS]: New macro.
+
+       * toplev.c [flag_signaling_nans]: Initialize to false.
+        (f_options): Add processing for "-fsignaling-nans".
+       (set_fast_math_flags): Clear flag_signaling_nans with -ffast-math.
+       (process_options): flag_signaling_nans implies flag_trapping_math.
+
+       * c-common.c (cb_register_builtins): Define __SUPPORT_SNAN__
+       when -fsignaling-nans.  First step to implementing WG14's N965.
+
+       * fold-const.c (fold) [MULT_EXPR]: Conditionalize transforming
+       1.0 * x into x, and -1.0 * x into -x on !HONOR_SNANS.
+       [RDIV_EXPR]: Conditionalize x/1.0 into x on !HONOR_SNANS.
+
+       * simplify-rtx.c (simplify_relational_operation): Conditionalize
+       transforming abs(x) < 0.0 into false on !HONOR_SNANS.
+
+       * rtlanal.c: #include real.c for TARGET_FLOAT_FORMAT definitions
+       required by HONOR_SNANS.  (may_trap_p): Floating point DIV, MOD,
+       UDIV, UMOD, GE, GT, LE, LT and COMPARE may always trap with 
+       -fsignaling_nans.  EQ and NE only trap for flag_signaling_nans 
+       not flag_trapping_math (i.e. HONOR_SNANS but not HONOR_NANS).
+
+       * doc/invoke.texi: Document new -fsignaling-nans compiler option.
+

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: gcc bootstrap broken on i686-linux-gnu

[Roger Sayle]

> /cvs/gcc/libjava/interpret.cc:3170: internal compiler error: RTL check:
>    expected code `reg', have `subreg' in split_2, at insn-recog.c:61241
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
> I nailed it down to this patch.  Bootstrapping with that patch
> applied causes the ICE, without it everything seems to be fine.
>
> Roger, can you investigate, please?

Certainly.  Sorry for any inconvenience.  The two possible
changes in behaviour are that -1.0*x is now tranformed into
-x by default (this previously only happened with -ffast-math),
and that "==" and "!=" no longer trap with default options.
One or both of these may be interacting badly with another
part of the compiler.

I'll keep you informed as I progress.  I should have a fix
or a work-around by the end of the day.

Roger
--

Re: gcc bootstrap broken on i686-linux-gnu

[Andreas Jaeger]

Roger Sayle <roger@eyesopen.com> writes:

>> /cvs/gcc/libjava/interpret.cc:3170: internal compiler error: RTL check:
>>    expected code `reg', have `subreg' in split_2, at insn-recog.c:61241
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>>
>> I nailed it down to this patch.  Bootstrapping with that patch
>> applied causes the ICE, without it everything seems to be fine.
>>
>> Roger, can you investigate, please?
>
> Certainly.  Sorry for any inconvenience.  The two possible
> changes in behaviour are that -1.0*x is now tranformed into
> -x by default (this previously only happened with -ffast-math),
> and that "==" and "!=" no longer trap with default options.
> One or both of these may be interacting badly with another
> part of the compiler.
>
> I'll keep you informed as I progress.  I should have a fix
> or a work-around by the end of the day.

That's fast - it gives you 6 more hours for my end of the day ;-)
(take your time to fix it properly, I can wait another day)

If you cannot reproduce it, ask me and I can try to send more details.

Thanks!
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: gcc bootstrap broken on i686-linux-gnu

[Graham Stott]

Andreas,

I think Roger's patch just tickles a problem in the x86 backend.

register_operand may also match SUBREG which isn't valid for the
REGNO macro hence the abort when enable checking is enabled.

I think the uses of FP_REGNO_P (REGNO (...)) should be FP_REG_P (...)
which checks it's operand is a REG before checking the REGNO.

I've got such a patch in the works.

Graham

Re: gcc bootstrap broken on i686-linux-gnu

[Roger Sayle]

Hi Graham,
> I think Roger's patch just tickles a problem in the x86 backend.
>
> register_operand may also match SUBREG which isn't valid for the
> REGNO macro hence the abort when enable checking is enabled.
>
> I think the uses of FP_REGNO_P (REGNO (...)) should be FP_REG_P (...)
> which checks it's operand is a REG before checking the REGNO.
>
> I've got such a patch in the works.

Excellent.  Many thanks.  I've just posted to the gcc list mentioning
my hypothesis that it could be the i386.md patterns at fault.

Roger
--

Re: gcc bootstrap broken on i686-linux-gnu

[Andreas Jaeger]

Graham Stott <graham.stott@btinternet.com> writes:

> Andreas,
>
> I think Roger's patch just tickles a problem in the x86 backend.
>
> register_operand may also match SUBREG which isn't valid for the
> REGNO macro hence the abort when enable checking is enabled.
>
> I think the uses of FP_REGNO_P (REGNO (...)) should be FP_REG_P (...)
> which checks it's operand is a REG before checking the REGNO.
>
> I've got such a patch in the works.

The bootstrap problem still exists for me.  I haven't tested Graham's
patch but I've noticed that it's unreviewed and I expect it to solve
the problem.  Can somebody review it, please?

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: gcc bootstrap broken on i686-linux-gnu

[Roger Sayle]

On Thu, 1 Aug 2002, Andreas Jaeger wrote:
> Graham Stott <graham.stott@btinternet.com> writes:
> > I think Roger's patch just tickles a problem in the x86 backend.
> >
> > register_operand may also match SUBREG which isn't valid for the
> > REGNO macro hence the abort when enable checking is enabled.
> >
> > I think the uses of FP_REGNO_P (REGNO (...)) should be FP_REG_P (...)
> > which checks it's operand is a REG before checking the REGNO.
> >
> > I've got such a patch in the works.
>
> The bootstrap problem still exists for me.  I haven't tested Graham's
> patch but I've noticed that it's unreviewed and I expect it to solve
> the problem.  Can somebody review it, please?

Make that two requests for someone to review this patch.  The patch
itself is at http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01753.html

Many thanks in advance,

Roger
--

Re: gcc bootstrap broken on i686-linux-gnu

[Roger Sayle]

On Mon, 29 Jul 2002, Andreas Jaeger wrote:
> Roger Sayle <roger@eyesopen.com> writes:
> >> /cvs/gcc/libjava/interpret.cc:3170: internal compiler error: RTL check:
> >>    expected code `reg', have `subreg' in split_2, at insn-recog.c:61241
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> >>
> >> I nailed it down to this patch.  Bootstrapping with that patch
> >> applied causes the ICE, without it everything seems to be fine.
> >>
> >> Roger, can you investigate, please?
> >
> > Certainly.  Sorry for any inconvenience.  The two possible
> > changes in behaviour are that -1.0*x is now tranformed into
> > -x by default (this previously only happened with -ffast-math),
> > and that "==" and "!=" no longer trap with default options.
> > One or both of these may be interacting badly with another
> > part of the compiler.
> >
> > I'll keep you informed as I progress.  I should have a fix
> > or a work-around by the end of the day.
>
> That's fast - it gives you 6 more hours for my end of the day ;-)
> (take your time to fix it properly, I can wait another day)
>
> If you cannot reproduce it, ask me and I can try to send more details.

Hi Andreas,

By a strange coincidence, I've been trying to track down an ICE
building the powerpc tool chain on i686-pc-linux-gnu, so I last
night I tried my first ever "--enable-checking" bootstrap.  This
morning I arrived at the office to find it had stopped in libjava
on exactly the problem you mentioned.

It looks like it is the -1.0*x to -x optimization that's triggering
the problem, the failure is in the split_all_insns pass that's
trying to split the following instruction:

(insn:HI 4951 4950 4957 212 0x4057a8c0 (parallel [
            (set (subreg:DF (reg/v:DI 1199) 0)
                (neg:DF (reg/v:DF 1193)))
            (clobber (reg:CC 17 flags))
        ]) 372 {*negdf2_if} (insn_list 4941 (nil))
    (expr_list:REG_DEAD (reg/v:DF 1193)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))


I'm currently trying to work out whether (1) its the code that generated
the (subreg:DF (reg:DI x) 0) that's at fault, (2) whether there's an
incorrect constraint in the i386.md patterns, or (3) its an issue with
genrecog generating an incorrect split_insns implementation.

Anyone?  anyone?

Roger
--