Bug 501807 - gcc
gcc
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Jakub Jelinek
BaseOS QE
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 15:21 EDT by Michael Jennings (KainX)
Modified: 2010-09-02 14:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-02 14:19:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple C file for reproducer (51 bytes, application/octet-stream)
2009-05-20 15:22 EDT, Michael Jennings (KainX)
no flags Details
Correct ASM output (841 bytes, application/octet-stream)
2009-05-20 15:23 EDT, Michael Jennings (KainX)
no flags Details
Actual ASM output (868 bytes, application/octet-stream)
2009-05-20 15:23 EDT, Michael Jennings (KainX)
no flags Details

  None (edit)
Description Michael Jennings (KainX) 2009-05-20 15:21:59 EDT
Description of problem:
gcc 4.1.2 on RHEL 5.3 does not produce correct Intel assembly code when given the "-masm=intel" flag.  Specifically, percent signs are appearing in the register variable names.

Version-Release number of selected component (if applicable):  4.1.2-42.el5


How reproducible:  100%


Steps to Reproduce:
1.  Create simple C program (e.g., attached foo.c)
2.  Compile with gcc -S -masm=intel foo.c
3.  There is no step 3!  ;-)
  
Actual results:
foo.s (attached) has RHEL5 gcc's results.

Expected results:
foo1.s (also attached) has the correct results as taken from a Caos system (gcc 4.3.3).

Additional info:
Here's a diff to show where the two provided examples differ specifically:
--- foo1.s      2009-05-19 16:56:44.000000000 -0700
+++ foo.s       2009-05-20 12:06:11.000000000 -0700
@@ -1,17 +1,17 @@
        .file   "foo.c"
-       .intel_syntax noprefix
+       .intel_syntax
        .text
 .globl main
        .type   main, @function
 main:
 .LFB2:
-       push    rbp
+       push    %rbp
 .LCFI0:
-       mov     rbp, rsp
+       mov     %rbp, %rsp
 .LCFI1:
-       mov     DWORD PTR [rbp-4], edi
-       mov     QWORD PTR [rbp-16], rsi
-       mov     eax, 0
+       mov     DWORD PTR [%rbp-4], %edi
+       mov     QWORD PTR [%rbp-16], %rsi
+       mov     %eax, 0
        leave
        ret
 .LFE2:
@@ -54,5 +54,5 @@
        .uleb128 0x6
        .align 8
 .LEFDE1:
-       .ident  "GCC: (GNU) 4.3.3"
+       .ident  "GCC: (GNU) 4.1.2 20071124 (Red Hat 4.1.2-42)"
        .section        .note.GNU-stack,"",@progbits

Note the "noprefix" which is missing in gcc 4.1.2's output.  Lack of the % prefix is necessary for true Intel ASM syntax.
Comment 1 Michael Jennings (KainX) 2009-05-20 15:22:58 EDT
Created attachment 344867 [details]
Simple C file for reproducer
Comment 2 Michael Jennings (KainX) 2009-05-20 15:23:31 EDT
Created attachment 344868 [details]
Correct ASM output
Comment 3 Michael Jennings (KainX) 2009-05-20 15:23:55 EDT
Created attachment 344869 [details]
Actual ASM output
Comment 4 Jakub Jelinek 2010-09-02 05:52:59 EDT
It produces valid assembly that gas accepts, I don't consider this a bug.
Comment 5 Michael Jennings (KainX) 2010-09-02 14:12:03 EDT
The parameter -masm=intel is supposed to produce Intel ASM output.  It failed to do so.  That's a bug.

Just because GAS accepts it doesn't mean it's correct Intel ASM.  What determines that is whether or not the Intel assembler accepts it, but that's not the case.  That definitely sounds like a bug to me.

If Red Hat's position is to not support their customers in High Performance Computing who make use of the Intel Compiler Suite, then that should be explicitly stated.  I'm sure my colleagues here at LBL would be very interested in knowing that.  :-)
Comment 6 Jakub Jelinek 2010-09-02 14:19:49 EDT
It produces Intel syntax in prefix mode.
If you want the noprefix syntax, you can use gcc44 -masm=intel.
The changes for -masm=intel post gcc 4.1.x are large and too risky to be backported.
Comment 7 Michael Jennings (KainX) 2010-09-02 14:27:28 EDT
(In reply to comment #6)
> The changes for -masm=intel post gcc 4.1.x are large and too risky to be
> backported.

If that's the rationale, I can understand and appreciate that.

I don't necessarily agree with "NOTABUG" (as opposed to "WONTFIX"), but I'll try not to quibble over details.  ;-)

Thanks for the explanation!  I'll pass this along to my customer.

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