[Bug c/19920] New: avr target build broken by recent 'DC' type update to libgcc2

[Bug c/19920] New: avr target build broken by recent 'DC' type update to libgcc2

[schlie at comcast dot net]

As of a few hours ago, avr target build broken by recent 'DC' type update to libgcc2.

In file included from /Applications/avr/avr-src/gcc/libgcc2.c:56:
/Applications/avr/avr-src/gcc/libgcc2.h:96: error: unable to emulate 'DC'
make[2]: *** [libgcc/./_muldi3.o] Error 1

-- 
           Summary: avr target build broken by recent 'DC' type update to
                    libgcc2
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schlie at comcast dot net
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.8.0
  GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: avr-unknown-none


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

[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-12 05:46 -------
This is a complex mode of DFmode.  Is DFmode supported at all on avr? If not, why not?

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


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

[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-12 07:59 -------
Subject: Re:  avr target build broken by recent 'DC'
 type update to libgcc2

> This is a complex mode of DFmode. Is DFmode supported at all on avr?

- no, but doubles are defined as being the same size as floats so that
  shouldn't represent a problem.

  libgcc2 should be basing it's built-in function definitions on the
  type sizes the target defines, not assume them to be of certain modes.

  More specifically, libgcc2 should be defining built-in's based on the
  target's type sizes which may be larger than it's MAX_FIXED_MODE_SIZE,
  (and presumably MAX_FLOAT_MODE_SIZE if it were defined), and properly
  specify their modes based on these specified type sizes, not some
  presumptions based on the size of the target's machine word size, as
  it's largely irrelevant. For example if a target defines:

  #define CHAR_TYPE_SIZE 8
  #define SHORT_TYPE_SIZE 8
  #define INT_TYPE_SIZE 16
  #define LONG_TYPE_SIZE 32
  #define LONG_LONG_TYPE_SIZE 64

  #define MAX_FIXED_MODE_SIZE 32

  #define FLOAT_TYPE_SIZE 32
  #define DOUBLE_TYPE_SIZE 32
  #define LONG_DOUBLE_TYPE_SIZE 32

  #define MAX_FLOAT_MODE_SIZE 0

  It should be presumed that the target will have defined implementations
  for standard integer modes char/short(QI),int(HI),long(HI) instructions,
  but any built-in's required for types larger than the maximum-mode-size
  would need to be defined (with their corresponding correct type modes).

  Implying libgcc2 would need to either use the above defined type-modes,
  and/or define long-long(DI), float(SF), double(SF), complex-float(CF),
  and complex-double(CF); as required to satisfy any built-in requirements.

> If not, why not?

- most simply because DF mode register demands exceed avr's available
  resources; and secondarily it exceeds the demands for typical avr
  class applications in terms of the value of it's precision vs demand
  for machine resources, vs. performance, (as C typically implies double
  precision for transcendental operations by default, for example), etc.

  [actually even long-long(DI) support is likely overkill, but gcc can't
   build without DI mode support as exception headers are defined as
   requiring 64 bits, which it likely shouldn't as it's an unnecessary
   requirement apparently derived from ia64 code; likely benefiting all
   32 bit or less machines, and should likely be relaxed.]

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.




-- 


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

[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2

[bjoern dot m dot haase at web dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bjoern dot m dot haase at
                   |                            |web dot de


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|avr target build broken by  |[4.0 Regression] avr target
                   |recent 'DC' type update to  |build broken by recent 'DC'
                   |libgcc2                     |type update to libgcc2


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-02-12 20:15 -------
I can confirm that the bug is present also for an intel-based linux system. 
 
In my opinion it is absolutely not useful to define a DF mode type on the AVR 
platform. Both excecution time and memory footprint would probably so large 
that they will not be of any relevance. What one could possibly consider IMHO 
is the implementation of a 3-Byte floating-point type with a 16 bit mantissa. 
 
Is there any know workaround so far? 
 
Yours, 
 
Björn 

-- 


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-02-12 21:08 -------
After changing line #96 in libgcc2.h from 
 
typedef _Complex float DCtype __atribute__ ((mode (DC))); 
 
to 
 
typedef _Complex float DCtype __atribute__ ((mode (SC))); 
 
it is again possible to build the avr port. 
In my opinion the best method for dealing with this problem would be to make  
sure some way that the #define symbols from the target header file are  
already known when compiling libgcc2 prior to including libgcc2.h. Then one  
would have the possibility to bracked line #96  within #ifndef #endif  
statements. 
 
Yours, 
 
Björn. 

-- 


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-13 00:10 -------
Subject: Re:  [4.0 Regression] avr target build broken
 by recent 'DC' type update to libgcc2

Or simpler, for each target (as gcc libgcc2 has trouble figuring it out):

  #define CHAR_MODE QI
  #define SHORT_MODE HI
  #define INT_MODE HI
  #define LONG_MODE SI
  #define LLONG_MODE DI
  #define FLOAT_MODE SF
  #define DOUBLE_MODE SF
  #define LDOUBLE_MODE SF

 (where then if desired
  #define INT_TYPE_SIZE ( MODE_SIZE( INT_MODE ) * UNITS_PER_WORD )
  ...)

Then within libgcc2, simply replace all the error prone logic with:

  typedef          int   CHAR_T     __attribute__ ((mode (CHAR_MODE)));
  typedef          int   SHORT_T    __attribute__ ((mode (SHORT_MODE)));
  typedef          int   INT_T      __attribute__ ((mode (INT_MODE)));
  typedef          int   LONG_T     __attribute__ ((mode (LONG_MODE)));
  typedef          int   LLONG_T    __attribute__ ((mode (LLONG_MODE)));
  typedef          float FLOAT_T    __attribute__ ((mode (FLOAT_MODE)));
  typedef          float DOUBLE_T   __attribute__ ((mode (DOUBLE_MODE)));
  typedef          float LDOUBLE_T  __attribute__ ((mode (LDOUBLE_MODE)));
  typedef _Complex float CFLOAT_T   __attribute__ ((mode (FLOAT_MODE)));
  typedef _Complex float CDOUBLE_T  __attribute__ ((mode (DOUBLE_MODE)));
  typedef _Complex float CLDOUBLE_T __attribute__ ((mode (LDOUBLE_MODE)));

 (where then one could define macros to define correctly named built-ins:
  #define SYMBOL2(a,b)    a ## b
  #define SYMBOL3(a,b)    a ## b ## c

  extern CFLOAT_T SYMBOL3(__add,CFLOAT_MODE,3)( CFLOAT_T, CFLOAT_T );

  ... to define built-in functions with correct types and mode names. Which
  seems much preferred and less error prone than attempting to at best guess
  a targets defined supported type sizes and corresponding modes; and then
  use them to define built-in functions named after the wrong modes...)

... hypothetically.







-- 


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-02-14 11:12 -------
Regression confirmed for avr-*-rtems* (20050214).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ralf dot corsepius at rtems
                   |                            |dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-14 11:12:12
               date|                            |


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

[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-02-14 11:34 -------
*** Bug 19949 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |corsepiu at gcc dot gnu dot
                   |                            |org


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

[Bug target/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[steven at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org
  GCC build triplet|powerpc-apple-darwin7.8.0   |
   GCC host triplet|powerpc-apple-darwin7.8.0   |
 GCC target triplet|avr-unknown-none            |
            Summary|[4.0 Regression] avr target |[4.0 Regression] build
                   |build broken by recent 'DC' |broken on several targets
                   |type update to libgcc2      |due to recent 'DC' type
                   |                            |update to libgcc2
   Target Milestone|---                         |4.0.0


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

[Bug target/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-02-14 12:01 -------
(In reply to comment #7)
> *** Bug 19949 has been marked as a duplicate of this bug. ***
OK, then for completeness: 
Regression confirmed for h8300-*-rtems* (GCC-4.0 20050214).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ralf dot corsepius at rtems |joel at oarcorp dot com
                   |dot org                     |


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 15:14 -------
None of the primary/secondary targets are known to fail so removing the target milestone.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |---


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-14 20:32 -------
(In reply to comment #9)
> None of the primary/secondary targets are known to fail so removing the target milestone.

Although I understand none of the failures are on primary/secondary targets, might someone who is 
most familiar with, and intends to hopefully maintain libgcc2 have a chance to look at this, in hopes it 
may be remedied relatively easily in a way consistent with their longer term plans?


-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-02-14 22:21 -------
FYI, 
 
I have just posted a RFC on gcc@gcc.gnu.org concerning implementation of a 
target-specific mode-substitution convention. Hopefully someone competent will 
answer. 
 
Yours, 
 
Björn. 
 

-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-15 20:42 -------
A call for testing patch is here: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build, patch


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-02-15 23:24 -------
FYI: I have just tested the patch posted in  
 
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html 
 
After applying this patch, the build for the avr target again succeeds. 
  
Yours,  
  
Björn  

-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-02-16 07:35 -------
(In reply to comment #12)
> A call for testing patch is here:
<http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html>.

With this patch applied, GCC-4.0 (20050216) builds again for
avr-rtems* and h8300-rtems*.

While building, I noticed warnings from math code in newlib, I haven't noticed
before. I am not sure whether these warnings had been present before or not and
if these are related to this patch.

-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-16 11:16 -------
Subject: Re:  [4.0 Regression] build broken on
 several targets due to recent 'DC' type update to libgcc2

> From: corsepiu at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> While building, I noticed warnings from math code in newlib, I haven't
> noticed before. I am not sure whether these warnings had been present
> before or not and if these are related to this patch.

Like ...?




-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-02-16 15:15 -------
(In reply to comment #15)
> > From: corsepiu at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> > While building, I noticed warnings from math code in newlib, I haven't
> > noticed before. I am not sure whether these warnings had been present
> > before or not and if these are related to this patch.
> 
> Like ...?

Here's one (target: h8300-rtems4.7):
../../../../../../gcc-4.0.0/newlib/libm/math/ef_remainder.c:49: warning: left
shift count >= width of type

There are dozens of similar warnings in my build-log.
Having a look into newlib shows all of these warnings to be related to
sizeof(int) vs. sizeof(long) vs. sizeof(void*), not to float/double.
I know newlib, is partially broken, in assuming
sizeof(int)==sizeof(long)==sizeof(void*)==32bit, but ...

... I have several local patches to newlib applied, which are supposed to fix
them. So, unless something has changed these sizes, I probably didn't work
carefully enough.

-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-16 15:56 -------
Subject: Re:  [4.0 Regression] build broken on
 several targets due to recent 'DC' type update to libgcc2

>> Like ...?
> 
> Here's one (target: h8300-rtems4.7):
> ../../../../../../gcc-4.0.0/newlib/libm/math/ef_remainder.c:49: warning: left
> shift count >= width of type
> 
> There are dozens of similar warnings in my build-log.
> Having a look into newlib shows all of these warnings to be related to
> sizeof(int) vs. sizeof(long) vs. sizeof(void*), not to float/double.
> I know newlib, is partially broken, in assuming
> sizeof(int)==sizeof(long)==sizeof(void*)==32bit, but ...
> 
> ... I have several local patches to newlib applied, which are supposed to fix
> them. So, unless something has changed these sizes, I probably didn't work
> carefully enough.

Although there may be remaining problems in libgcc2; it would seem
prudent for newlib (and possibly even libgcc2 as may be required) to
be more explicit, i.e. use int16, int32, etc. vs. short, int, long; or
conditionally declare types based on sizeof(), when a type needs to be
a certain or relative size for the code to work as intended.

(not great, but good to know it doesn't seem to be a libgcc2 problem)




-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[rth at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-02-14 11:12:12         |2005-02-16 22:54:27
               date|                            |


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-16 22:55 -------
Subject: Bug 19920

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2005-02-16 22:55:34

Modified files:
	gcc            : ChangeLog libgcc2.c libgcc2.h 

Log message:
	PR 19920
	* libgcc2.c (WORD_SIZE): Remove all definitions; replace uses
	with W_TYPE_SIZE.
	(HIGH_WORD_COEFF, HIGH_HALFWORD_COEFF): Remove all definitions;
	replace uses with Wtype_MAXp1_F.
	(L_fixunstfdi, L_fixtfdi, L_floatditf, L_fixunsxfdi, L_fixxfdi,
	L_floatdixf, L_fixunsxfsi, L_fixunsdfdi, L_floatdidf, L_fixunsdfsi,
	L_powidf2, L_powixf2, L_powitf2, L_muldc3, L_divdc3, L_mulxc3,
	L_divxc3, L_multc3, L_divtc3): Protect with HAVE_DFMODE, HAVE_XFMODE,
	and HAVE_TFMODE as appropriate.
	(__fixunssfDI): Provide an implementation that doesn't need DFmode.
	(__floatdisf): Likewise.
	* libgcc2.h (LIBGCC2_DOUBLE_TYPE_SIZE): New.
	(HAVE_DFMODE, HAVE_XFMODE, HAVE_TFMODE): New.
	(Wtype_MAXp1_F): New.
	(DFtype, DCtype, __fixdfdi, __floatdidf, __fixunsdfSI, __fixunsdfDI,
	__powidf2, __divdc3, __muldc3): Protect with HAVE_DFMODE.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7499&r2=2.7500
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c.diff?cvsroot=gcc&r1=1.183&r2=1.184
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.h.diff?cvsroot=gcc&r1=1.36&r2=1.37



-- 


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-02-17 18:27 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.0


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