Bug 38617 - ICE passing fixed point to function
Summary: ICE passing fixed point to function
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ABI, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2008-12-24 11:53 UTC by Chris Fairles
Modified: 2009-02-18 02:23 UTC (History)
3 users (show)

See Also:
Host: x86_64-redhat-linux
Target: x86_64-redhat-linux
Build: x86_64-redhat-linux
Known to work: 4.4.0
Known to fail:
Last reconfirmed: 2008-12-24 13:54:17


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Fairles 2008-12-24 11:53:51 UTC
template<class T>
void foo(T) { } // 2

int main()
{
  foo(0r); // 6
}

Gives:

fixed.cpp: In function 'void foo(T) [with T = <unnamed-fixed:16>]':
fixed.cpp:6:   instantiated from here
fixed.cpp:2: internal compiler error: in classify_argument, at config/i386/i386.c:5123


Chris
Comment 1 Chris Fairles 2008-12-24 12:00:49 UTC
cc'ing andrew
Comment 2 Andrew Pinski 2008-12-24 13:54:17 UTC
x86_64 does not support fixed point modes at all.  Someone needs to come up with an ABI for it.

Note it works in 32bit mode ...
Comment 3 H.J. Lu 2008-12-24 16:20:59 UTC
What are fixed point types? What need to implement to support fixed
point types? Does gcc testsuite have any fixed point tests?
Comment 4 Chris Fairles 2008-12-24 16:44:02 UTC
(In reply to comment #3)
> What are fixed point types?

http://gcc.gnu.org/wiki/FixedPointArithmetic
Comment 5 joseph@codesourcery.com 2008-12-24 17:28:47 UTC
Subject: Re:  ICE passing fixed point to function

On Wed, 24 Dec 2008, pinskia at gcc dot gnu dot org wrote:

> x86_64 does not support fixed point modes at all.  Someone needs to come up
> with an ABI for it.

If the user configured with --enable-fixed-point on a target not 
supporting it (i.e. anything other than MIPS) then they should expect 
ICEs; they should only configure that way when working on adding the 
support.

If they didn't configure with that option the compiler should give 
sensible errors rather than ICEs.

I don't know which is the case here.

Comment 6 Chris Fairles 2008-12-24 17:33:13 UTC
(In reply to comment #5)
> Subject: Re:  ICE passing fixed point to function
>
> If they didn't configure with that option the compiler should give 
> sensible errors rather than ICEs.
> 
> I don't know which is the case here.
> 

Configured with: ../gcc/configure --disable-multilib --enable-clock-gettime=rt --program-suffix=44 --enable-languages=c,c++

That is, no --enable-fixed-point.
Comment 7 H.J. Lu 2008-12-24 17:55:46 UTC
I verified that there is

auto-host.h:#define ENABLE_FIXED_POINT 0

But I still got ICE:

bash-3.2$ cat /tmp/f.c
extern void foo(Fract);

int main()
{
  foo(0r);
}

bash-3.2$ ./xgcc -B./ -S /tmp/f.c
/tmp/f.c:1: warning: parameter names (without types) in function declaration
/tmp/f.c: In function ‘main’:
/tmp/f.c:5: internal compiler error: in classify_argument, at config/i386/i386.c:5132
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
bash-3.2$ 
Comment 8 H.J. Lu 2008-12-24 17:59:34 UTC
It seemslike even if fixed point isn't supported, gcc still
recognizes "0r". 
Comment 9 joseph@codesourcery.com 2008-12-24 18:01:58 UTC
Subject: Re:  ICE passing fixed point to function

On Wed, 24 Dec 2008, hjl dot tools at gmail dot com wrote:

> I verified that there is
> 
> auto-host.h:#define ENABLE_FIXED_POINT 0
> 
> But I still got ICE:

Then the bug is in one or both front ends: a missing 
targetm.fixed_point_supported_p call, or a failure to act appropriately on 
the results of such a call.

Comment 10 H.J. Lu 2008-12-24 18:24:36 UTC
This works for me:

--- ./c-lex.c.fixed	2008-08-21 05:32:03.000000000 -0700
+++ ./c-lex.c	2008-12-24 10:23:52.000000000 -0800
@@ -612,7 +612,15 @@ interpret_float (const cpp_token *token,
 
   /* Decode _Fract and _Accum.  */
   if (flags & CPP_N_FRACT || flags & CPP_N_ACCUM)
-    return interpret_fixed (token, flags);
+    {
+      if (targetm.fixed_point_supported_p ())
+	return interpret_fixed (token, flags);
+      else
+	{
+	  error ("fixed-point constant not supported for this target");
+	  return error_mark_node;
+	}
+    }
 
   /* Decode type based on width and properties. */
   if (flags & CPP_N_DFLOAT)
Comment 11 Rob 2009-01-06 15:54:12 UTC
(In reply to comment #5)
> Subject: Re:  ICE passing fixed point to function
> 
> On Wed, 24 Dec 2008, pinskia at gcc dot gnu dot org wrote:
> 
> > x86_64 does not support fixed point modes at all.  Someone needs to come up
> > with an ABI for it.
> 
> If the user configured with --enable-fixed-point on a target not 
> supporting it (i.e. anything other than MIPS) then they should expect 
> ICEs; they should only configure that way when working on adding the 
> support.
> 
> If they didn't configure with that option the compiler should give 
> sensible errors rather than ICEs.
> 
> I don't know which is the case here.
> 

I tried --enable-fixed-point on i386-pc-solaris2.11 and got an ice-on-valid-code 
see here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34422#c4

Rob
Comment 12 Joseph S. Myers 2009-02-18 01:32:21 UTC
GCC now properly gives errors for fixed-point in C++ and fixed-point in C
on targets that don't support it after Jakub's patch for bug 39059.  So
there is no longer a C front-end bug here.  That most targets don't support
it is a missing feature for those targets, not a bug, and supporting it would
require an ABI to be worked out first for any target with support added.