[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #11 from hubicka at ucw dot cz  2005-10-02 21:46 -------
Subject: Re:  [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed
and decimal arithmetic broken

> 
> 
> ------- Comment #10 from laurent at guerby dot net  2005-10-02 16:20 -------
> It looks like it is indeed a codegen bug in s-arit64.adb, in Scaled_Divide the
> following line is miscompiled at -O1 and above (works at -O0):
> 
>             T2 := Lo (T1 rem Zlo) & D (4);
> 
> In my p.adb testcase, the compiler with Jan patch calls Lo with argument = 0
> whereas (T1 rem Zlo) returned (1073741824 rem 3221225472) = 1073741824 so
> stack/argument handling must be confused at some point. 
> 
> The bug is volatile, ie replacing the line above by:
> 
>             S3 := Lo (T1 rem Zlo);
>             if S3 = 0 then
>                T2 := Uns64 (D (4));
>             else
>                T2 := S3 & D (4);
>             end if;
> 
> Makes it go away.
Can you please check if -fno-tree-ter makes the bug go away?  We've
chatted recently with Jakub concerning bug in argument saving in nested
call and -maccumulate-outgoing-args.  I was under impression that we
should no longer produce the nested calls out of ter but aparently it is
still being done (that results in inferrior code quality too as we can't
generated nested calls very sanely)

Also can you also, please, point me closer to place in .optimized dump
where the misscompilation happens?  THere seems to be couple of lo calls
around.  I will be mostly offline tomorrow but should be able to fix it
day after that.

Thanks a lot!
Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003