[Bug c/59277] New: x86_64 code generation defects when SSE instructions are disabled

[Bug c/59277] New: x86_64 code generation defects when SSE instructions are disabled

[aron at udel dot edu]

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

            Bug ID: 59277
           Summary: x86_64 code generation defects when SSE instructions
                    are disabled
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aron at udel dot edu

There are a couple of defects in GCC for x86_64 targets when -mno-sse is
specified.

(1) SSE registers are still generated in various cases. For example, the
following codes will throw an error during compilation because SSE registers
are used:
   (1) double test() { return 0.0; }
   (2) void test (int n, ...) {
          va_list vl; va_start(vl, n);
          double foo = va_arg(vl, double);
          va_end(vl);
       }

(2) va_arg is broken for double types, independently of the bug listed above.
When '-mno-sse' is specified, floating-point numbers are pushed to the stack by
default instead of using the SSE registers; however, the current implementation
for va_arg still looks in the register save area for FP numbers and as such it
returns garbage values.

A fix for the latter should be pretty simple, along the lines of just
defaulting to overflow area for double types similar to the following:
    #define va_arg_double(va) \
        (*(double*)((va->overflow_arg_area += 8, va->overflow_arg_area

It looked to me like the code to generate the ABI implementation of va_list for
x86 targets is in gcc\config\i386\i386.c.

The only question I have is that I believe fixing these the defects breaks with
the x86_64 ABI specification and wonder whether this would be an issue because
of that.

[Bug target/59277] x86_64 code generation defects when SSE instructions are disabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |X86_64
          Component|c                           |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
1) I don't think this is a bug since the abi says to use SSE registers here. If
you want a different abi where SSE is not used you need to create a new abi

2) yes GCC is inconatsaint here but not really a bug due to an abi different.

[Bug target/59277] x86_64 code generation defects when SSE instructions are disabled

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Target|X86_64                      |x86_64-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-25
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
We still have to follow the ABI.  Of course I'd say with -mno-sse you
should get a fatal_error () whenever you run into an ABI piece that requires
SSE registers (instead of silently using them).

We may have one or more (near) duplicates of this bug.

[Bug target/59277] x86_64 code generation defects when SSE instructions are disabled

[aron at udel dot edu]

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

--- Comment #4 from Aaron Myles Landwehr <aron at udel dot edu> ---
That is completely fair. Correct me if I'm wrong here, but that also means that
any code that passes doubles as arguments should also get fatal_error() instead
of dropping arguments to the stack as is currently done.