Bug 169845 - "short" accessed as a 32-bit word with -O1
"short" accessed as a 32-bit word with -O1
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc (Show other bugs)
3.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
: 169842 169843 (view as bug list)
Depends On:
Blocks: 161600 168424 169792
  Show dependency treegraph
 
Reported: 2005-10-04 09:01 EDT by Miloslav Trmač
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2006-0147
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 10:29:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simplified reproducer (293 bytes, text/plain)
2005-10-04 09:01 EDT, Miloslav Trmač
no flags Details
Output - note line 15 (1.08 KB, text/plain)
2005-10-04 09:03 EDT, Miloslav Trmač
no flags Details
gcc32-pr13041.patch (1.31 KB, patch)
2005-10-04 17:36 EDT, Jakub Jelinek
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 13041 None None None Never

  None (edit)
Description Miloslav Trmač 2005-10-04 09:01:20 EDT
Description of problem:
The attached test case (derived from doset () in sh.set.c from tcsh)
should read "val = *ptr" using a 16-bit read, but it uses a 32-bit read.
When *ptr is located at end of a page, this can cause a SIGSEGV.

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

How reproducible:
gcc -S -O1 foo2.c && less foo2.s

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Miloslav Trmač 2005-10-04 09:01:24 EDT
Created attachment 119594 [details]
Simplified reproducer
Comment 2 Miloslav Trmač 2005-10-04 09:03:38 EDT
Created attachment 119595 [details]
Output - note line 15
Comment 3 Miloslav Trmač 2005-10-04 09:05:18 EDT
*** Bug 169842 has been marked as a duplicate of this bug. ***
Comment 4 Miloslav Trmač 2005-10-04 09:05:35 EDT
*** Bug 169843 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2005-10-04 16:50:06 EDT
The problem from quick look at it seems to be in register %rbp being used
and although it is not the hard frame pointer in that function, it is assumed
to have some properties of hard frame pointer, particularly alignment.
The movhi_1 insn will use movl rather than movw or movzw if it knows the
memory is 4 byte aligned.
Comment 6 Jakub Jelinek 2005-10-04 17:36:53 EDT
Created attachment 119632 [details]
gcc32-pr13041.patch

Backported patch that seems to fix it.
Comment 7 Keiichi Mori 2005-10-05 06:56:47 EDT
I applied the patch at comment#6 and compiled the test case and tcsh by it.

# cat foo2.s
        .file   "foo2.c"
        .text
.globl doset
        .type   doset,@function
doset:
.LFB2:
        subq    $24, %rsp
.LCFI0:
        movq    %rbx, 8(%rsp)
.LCFI1:
        movq    %rbp, 16(%rsp)
.LCFI2:
        movq    %rdi, %rbx
        movq    (%rdi), %rbp
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
        movzwl  (%rbp), %eax
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        testw   %ax, %ax
        je      .L3
        je      .L3
        movl    $0, %eax
        call    fn

# gdb ./tcsh
(gdb) disas doset
...
0x00000000004260af <doset+444>: lea    0x14(%rsp),%rsi
0x00000000004260b4 <doset+449>: mov    %rbp,%rdi
0x00000000004260b7 <doset+452>: callq  0x42623b <getinx>
0x00000000004260bc <doset+457>: mov    %rax,%rbp
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x00000000004260bf <doset+460>: movzwl 0x0(%rbp),%ebx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x00000000004260c3 <doset+464>: test   %bx,%bx
...

In both cases, movzwl is used instead of mov. Does this fact mean the problem is
fixed ?
Comment 14 Red Hat Bugzilla 2006-03-15 10:29:56 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0147.html

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