Bug 58065 - gcc-3.1-0.14 miscompiles kernel 2.4.18-pre1 rtc.o
Summary: gcc-3.1-0.14 miscompiles kernel 2.4.18-pre1 rtc.o
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-07 17:11 UTC by Need Real Name
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-02-05 21:08:00 UTC
Embargoed:


Attachments (Terms of Use)
Notice how hwclock --debug --systohc corrupts the hardware clock. (6.43 KB, text/plain)
2002-02-05 20:28 UTC, Need Real Name
no flags Details

Description Need Real Name 2002-01-07 17:11:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226

Description of problem:
gcc 3.1-0.14 successfully compiles kernel 2.4.18-pre1, and the resulting kernel
boots fine and most things work OK.  But, rtc.o does not work.  Specifically,
after a cold boot to the gcc-3.1-0.14 compiled kernel, hwclock always says it is
Jan 01 2001.  hwclock works fine if the gcc-3.1-0.14 compiled kernel is
warmbooted from a gcc-2.96-101.9 compiled kernel.

So presumably some initialization routine in rtc.o is miscompiled by
gcc-3.1-0.14?  I'm not sure how to further diagnose the problem--please let me
know what else I should do, as the information here is not very much.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Compile kernel 2.4.18-pre1 with gcc 3.1-0.14
2. Poweroff the machine
3. Upon booting the new kernel, hwclock always gives Jan 01 2001
	

Additional info:

rtc.o is a module
ASUS A7V motherboard with Athlon 1.0 GHz

Comment 1 Need Real Name 2002-02-04 20:22:09 UTC
This no longer occurs for me with gcc 3.1-0.20 and kernel 2.4.18-pre7-ac3.  So
I'm closing this bug, I hope RAWHIDE is the correct resolution to use, please
correct me if I'm wrong.


Comment 2 Need Real Name 2002-02-05 00:04:28 UTC
Oops, I spoke too soon:  gcc-3.1-0.20 and kernel 2.4.18-pre8 still shows the
hwclock problem.  Since mainline kernel shows the problem and -ac does not, I'm
not sure this is a compiler problem, but I thought I'd reopen the bug, since
gcc-2.96 is fine on both trees.  The funny thing is, drivers/char/rtc.c is the
same in mainline and -ac.

Please let me know if I can provide any other information that would be helpful,
I'm sure I've not provided enough but don't know what else to provide.

Comment 3 Need Real Name 2002-02-05 05:58:33 UTC
OK, either I'm very confused today or the success of gcc 3.1-0.20 on kernel
2.4.18-pre7-ac3 is intermittent.  I'm now again seeing the hwclock problem on
2.4.18-pre7-ac3, maybe my earlier successes were spurious?  Sorry about the noise.



Comment 4 Jakub Jelinek 2002-02-05 16:20:49 UTC
Well, I've tried to reproduce this myself but it worked for me.
Anyway, looking at the code differences between 2.96-RH and 3.1-0.21 compiled
rtc.o, the most visible one is that gcc 3.1 fails to inline a bunch of routines
and instead emits them out of line.
So, I wonder, does the bug go away if kernel is compiled with gcc 3.1
with -finline-limit=2000 additional option (well, for rtc.c already 1000
inlines all inline marked functions, but 2000 is a safe value for other places
too)?

Comment 5 Need Real Name 2002-02-05 20:26:20 UTC
OK, I did a bunch more tests, assuming that the only program that touches the
hardware clock is /sbin/hwclock.  Then I narrowed it down to this:  my hardware
clock gets corrupted when hwclock writes to it via /dev/rtc when the kernel is
compiled with gcc-3.1.  

This is true whether or not I use -finline-limit=2000 in compiling the kernel. 
Reading the hwclock via /dev/rtc works OK.  If I use hwclock --directisa,
everything works OK, in particular I can recover from the corrupted hwclock this
way.  And, of course, if I use gcc-2.96 to comiple the kernel, everything works
OK.  

The issue of doing a cold boot to see the problem was a red herring--it was just
that since the boot scripts don't write to the hwclock until shutdown, I had to
boot twice to see the problem in my usual routine.

A few details on my setup:  an ASUS A7V motherboard with Athlon Thunderbird
1000, kernel 2.4.18-pre8, gcc-3.1-0.20, rtc.o as a module.

I'm attaching the ouput of a bunch of hwclock runs that show the problem.  Let
me know if I can provide any more information, sorry it took me a while to
figure out the problem well enough to properly report it to you.

Comment 6 Need Real Name 2002-02-05 20:28:12 UTC
Created attachment 44597 [details]
Notice how hwclock --debug --systohc corrupts the hardware clock.

Comment 7 Jakub Jelinek 2002-02-05 20:50:02 UTC
Looking at what RTC_SET_TIME does:
                unsigned char mon, day, hrs, min, sec, leap_yr;
                unsigned char save_control, save_freq_select;
...
                        ((sec)=(((sec)/10)<<4) + (sec)%10);
                        ((min)=(((min)/10)<<4) + (min)%10);
                        ((hrs)=(((hrs)/10)<<4) + (hrs)%10);
                        ((day)=(((day)/10)<<4) + (day)%10);
                        ((mon)=(((mon)/10)<<4) + (mon)%10);
                        ((yrs)=(((yrs)/10)<<4) + (yrs)%10);
this looks very much like GCC PR c/5304 I've fixed 3 days ago
(gcc miscompiled division/modulo by certain constants for types smaller than
int, just tried unsigned char x = 30; x / 10 and it was miscompiled in gcc-3.1-0.20).
Could you please try ftp://people.redhat.com/jakub/gcc/3.1-0.21/ ?
Thanks.

Comment 8 Need Real Name 2002-02-05 21:07:54 UTC
Wow, that does the trick, gcc-3.1-0.21 compiles an rtc.o for which 'hwclock
--systohc' no longer corrupts the hwclock.  Looks like I was one point release
too speedy in looking into this again.

BTW, with gcc-3.1, is it better to use -finline-limit=2000 when compiling the
kernel?

Thanks,
Wayne



Comment 9 Jakub Jelinek 2002-02-06 15:37:46 UTC
Well, for now -finline-limit=2000 for kernel is a good thing to do,
this will be solved till gcc 3.1 final comes out definitely though.


Note You need to log in before you can comment on or make changes to this bug.