[Bug c/18887] New: libgcc2.h Improperly determines required built-in function size requirements.

[Bug c/18887] New: libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

UNITS_PER_WORD is being improperly used as the sole basis for selecting built-in
function type sizes in libgcc2.h.

As definitions like:

#if MIN_UNITS_PER_WORD > 1
/* These typedefs are usually forbidden on dsp's with UNITS_PER_WORD 1. */
typedef          int SItype     __attribute__ ((mode (SI)));
typedef unsigned int USItype    __attribute__ ((mode (SI)));
...

are basically wrong; an appropriate set of default built-in function definitions
should be generated for each unique target defined XXXX_TYPE_SIZE equal to or
larger than the targets's WORD_SIZE (which equals UNITS_PER_WORD * BITS_PER_UNIT).

Which isn't what the embedded logic does, it just happens to work for most larg
 platforms as their UNITS_PER_WORD is large enough not to expose it's faults, as
evedenced on 8-bit targets for exampe which would benefit from some word-size
(8-bit QI) defaults for mul/div for example, along with built-in definitions for each
of it's potentially defined multi-word defined types, which may include 16bit (HI),
32bit(SI), 64bit(DI), 16bit (HF), 32bit(SF), and 64bit(DF) types, which clearly wouldn't
be defined by inspection.

So suspect that the logic should look more like:

#define WORD_SIZE (UNITS_PER_WORD * BITS_PER_UNIT)

#if   CHAR_TYPE_SIZE ==  8 || SHORT_TYPE_SIZE ==  8
#define GENERATE_QI_MODE_DEFINITIONS
#  if WORD_SIZE == 8
#    define GENERATE_QI_MODE_BUILTIN_DEFAULTS_BASE
#  endif
#endif

#if   SHORT_TYPE_SIZE ==  16 || INT_TYPE_SIZE ==  16
#define GENERATE_HI_MODE_DEFINITIONS
#  if WORD_SIZE < 16
#    define GENERATE_HI_MODE_BUILTIN_DEFAULTS_ALL
#  elif WORD_SIZE == 16
#    define GENERATE_HI_MODE_BUILTIN_DEFAULTS_BASE
#  endif
#endif

#if   INT_TYPE_SIZE ==  32 || LONG_TYPE_SIZE ==  32
#define GENERATE_SI_MODE_DEFINITIONS
#  if WORD_SIZE < 32
#    define GENERATE_SI_MODE_BUILTIN_DEFAULTS_ALL
#  elif WORD_SIZE == 32
#    define GENERATE_SI_MODE_BUILTIN_DEFAULTS_BASE
#  endif
#endif

#if   LONG_TYPE_SIZE ==  64 || LONG_LONG_TYPE_SIZE ==  64
#define GENERATE_DI_MODE_DEFINITIONS
#  if WORD_SIZE < 64
#    define GENERATE_DI_MODE_BUILTIN_DEFAULTS_ALL
#  elif WORD_SIZE == 64
#    define GENERATE_DI_MODE_BUILTIN_DEFAULTS_BASE
#  endif
#endif

#if   LONG_LONG_TYPE_SIZE ==  128
#define GENERATE_TI_MODE_DEFINITIONS
#  if WORD_SIZE < 128
#    define GENERATE_TI_MODE_BUILTIN_DEFAULTS_ALL
#  elif WORD_SIZE == 128
#    define GENERATE_TI_MODE_BUILTIN_DEFAULTS_BASE
#  endif
#endif

#if   FLOAT_TYPE_SIZE ==  16
#define GENERATE_HF_MODE_DEFINITIONS
#define GENERATE_HF_MODE_BUILTIN_DEFAULTS_ALL
#endif

#if   FLOAT_TYPE_SIZE ==  32 || DOUBLE_TYPE_SIZE ==  32
#  define GENERATE_SF_MODE_DEFINITIONS
#  define GENERATE_SF_MODE_BUILTIN_DEFAULTS_ALL
#endif

#if   DOUBLE_TYPE_SIZE ==  64 || QUAD_TYPE_SIZE ==  64
#  define GENERATE_DF_MODE_DEFINITIONS
#  define GENERATE_DF_MODE_BUILTIN_DEFAULTS_ALL
#endif

#if   QUAD_TYPE_SIZE ==  128
#  define GENERATE_TF_MODE_DEFINITIONS
#  define GENERATE_TF_MODE_BUILTIN_DEFAULTS_ALL
#endif

or somthing like that, thereby all bultins as nessisary are properly defined by
default that are larger than the WORD_SIZE, with a few base defaults if equal
to the word size for functions typically not implemented in HW such as possiby
/ and %.

-- 
           Summary: libgcc2.h Improperly determines required built-in
                    function size requirements.
           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: any
  GCC host triplet: any
GCC target triplet: 8/16 bit targets


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

[Bug c/18887] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-08 14:36 -------
Is this really a bug as almost all 8/16bit targets provide their own libgcc1?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
            Summary|libgcc2.h Improperly        |libgcc2.h Improperly
                   |determines required built-in|determines required built-in
                   |function size requirements. |function size requirements.


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

[Bug c/18887] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2004-12-08 15:24 -------
Subject: Re:  libgcc2.h Improperly determines required
 built-in function size requirements.

> From: pinskia at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-08
> 14:36 -------
> Is this really a bug as almost all 8/16bit targets provide their own libgcc1?

Wouldn't call it critical, but given libgcc2's present selection logic
arguably needlessly prevents it's practical use on smaller platforms, I'm
sure it's contributed to the decision. (but regardless, would think it
would be preferable to remove future impediments to it's use).

[I'd be pleased to submit a patch, but would realistically require
 assistance verifying that the refinements don't create any regressions
 on existing platforms, would that be potentially acceptable?]





-- 


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

[Bug c/18887] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2004-12-08 20:25 -------
Subject: Re:  libgcc2.h Improperly determines required
 built-in function size requirements.

> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-08
> Is this really a bug as almost all 8/16bit targets provide their own libgcc1?

(good news / bad news, speak of the devil)

Here's a real bug, apparently recently introduced:

The avr build of today's GCC 4.0 fails because libgcc2 defines a DF mode
64-bit double built-in function although the target defines a SI mode 32-bit
double type; (as unfortunately the libgcc2.h code is basically garbage):

#if BITS_PER_UNIT == 8  { which has nothing to do with anything }

typedef     float SFtype    __attribute__ ((mode (SF)));
typedef     float DFtype    __attribute__ ((mode (DF)));
...

#if BITS_PER_UNIT == 8  { then defines a function with it }
extern DWtype __fixdfdi (DFtype);
...

Although avr.h defines:

#define DOUBLE_TYPE_SIZE 32

Resulting in:

/Applications/avr/gcc-build/gcc/xgcc -B/Applications/avr/gcc-build/gcc/
-B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include
-isystem /usr/local/avr/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -DDF=SF -Dinhibit_libc
-mcall-prologues -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc
-I. -I -I../../gcc/gcc -I../../gcc/gcc/ -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  -DL_fixdfdi -c ../../gcc/gcc/libgcc2.c -o
libgcc/./_fixdfdi.o
../../gcc/gcc/libgcc2.c: In function '__fixdfdi':
../../gcc/gcc/libgcc2.c:1198: internal compiler error: in find_valid_class,
at reload.c:712
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [libgcc/./_fixdfdi.o] Error 1
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2





-- 


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

[Bug c/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-12-11 16:37 -------
Given that this breaks bootstrap of the AVR platform, I'm marking this as a 
regression. Paul, go ahead and submit your patch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |4.0.0
      Known to work|                            |3.4.2
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-11 16:37:47
               date|                            |
            Summary|libgcc2.h Improperly        |[4.0 Regression] libgcc2.h
                   |determines required built-in|Improperly determines
                   |function size requirements. |required built-in function
                   |                            |size requirements.
   Target Milestone|---                         |4.0.0


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-11 17:58 -------
P3 because almost all of the embedded targets (and especially the 8/16bit ones) are not primary 
targets.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-12 03:09 -------
Also could you file another bug for not rejecting the use of these modes because that seems like 
something which should have happened instead of the current ICE.  Please attach the preprocessed 
source for libgcc2.c when compiling for _fixdfdi.

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[bernie at develer dot com]

------- Additional Comments From bernie at develer dot com  2004-12-12 13:52 -------
*** Bug 18941 has been marked as a duplicate of this bug. ***

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[bernie at develer dot com]

------- Additional Comments From bernie at develer dot com  2004-12-12 14:11 -------
The ICE has been triggered by one of these patches:

diff -u -p -r2.6723 -r2.6731
--- gcc/ChangeLog	6 Dec 2004 12:32:21 -0000	2.6723
+++ gcc/ChangeLog	7 Dec 2004 03:52:13 -0000	2.6731
@@ -1,3 +1,66 @@
+2004-12-06  Ziemowit Laski  <zlaski@apple.com>
+
+	* c-tree.h (struct lang_type): Add 'objc_protocols' field.
+
+2004-12-06  DJ Delorie  <dj@redhat.com>
+
+	* reload.c (find_valid_class): Fix logic to test inner mode as well.
+	(push_reload): Pass inner mode.
+
+2004-12-06  Eric Christopher  <echristo@redhat.com>
+
+	* doc/tm.texi (TARGET_VALID_POINTER_MODE): Document.
+
+2004-12-06  Aldy Hernandez  <aldyh@redhat.com>
+
+	* config/rs6000/sysv4.h: Define RELOCATABLE_NEEDS_FIXUP to 1.
+
+2004-12-06  Zdenek Dvorak  <dvorakz@suse.cz>
+	    Kazu Hirata  <kazu@cs.umass.edu>
+
+	PR tree-optimization/18601
+	* tree-cfg.c (thread_jumps, thread_jumps_from_bb): Removed.
+	(tree_forwarder_block_p): Do not consider blocks that are its own
+	successors forwarders.
+	(cleanup_forwarder_blocks, remove_forwarder_block): New functions.
+	(cleanup_tree_cfg): Use cleanup_forwarder_blocks instead of
+	thread_jumps.
+	* tree-flow.h (bb_ann_d): Remove forwardable.
+
+2004-12-06  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* expr.c (expand_expr_real_1): Remove an "if" whose condition
+	is always false.
+
+2004-12-06  Roger Sayle  <roger@eyesopen.com>
+
+	* c-gimplify.c (gimplify_c_loop): Improve initial implementations
+	for loops whose conditions are known at compile-time.
+	* gimplify.c (append_to_statement_list_1): Remove side_effects
+	parameter, this function should never be called if its false.
+	(append_to_statement_list): Only call append_to_statement_list_1
+	if t is non-NULL tree with side-effects.
+	(append_to_statement_list_force):  Likewise, if t is not NULL.
+
+2004-12-06  J"orn Rennecke <joern.rennecke@st.com>
+
+	* bt-load.c (btr_def_s): New member own_end;
+	(add_btr_to_live_range): Add second parameter.  Changed caller.
+	(clear_btr_from_live_range): Clear btrs_live_at_end bit
+	for the register its definition basic block if own_end is set.
+	(augment_live_range): Also take btrs_live_at_end into account.
+	(combine_btr_defs): Don't bother with
+	other_def->other_btr_uses_after_use if it pertains to a different
+	register.
+	(move_btr_def): Set def->other_btr_uses_before_def after
+	calling combine_btr_defs."
+
+	* bt-load.c (augment_live_range): New argument full_range.
+	Changed all callers.
+
+	* bt-load.c (move_tr_def): Set other_tr_uses_before_def
+	taking new btr assignment into account.
+
 2004-12-05  Daniel Berlin <dberlin@dberlin.org>
 
 	* tree-ssa-alias.c (create_global_var): Use void_type_node,

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[bernie at develer dot com]

------- Additional Comments From bernie at develer dot com  2004-12-12 14:22 -------
More precisely, the ICE has been triggered by this patch:

+2004-12-06  DJ Delorie  <dj@redhat.com>
+
+	* reload.c (find_valid_class): Fix logic to test inner mode as well.
+	(push_reload): Pass inner mode.


The problem is not *in* this patch, but while waiting for
a proper fix, I could get GCC to build again for AVR by
reversing it locally.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 16:40 -------
*** Bug 18988 has been marked as a duplicate of this bug. ***

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2004-12-21 20:19 -------
Minimal changes required to get avr to build:
(which disables DI/DF emulation modes which appear to exceed avr's allocatable registers. )

*** In File: config/avr.h, Beginning line: 111 ***

  #define BITS_BIG_ENDIAN 0
  #define BYTES_BIG_ENDIAN 0
  #define WORDS_BIG_ENDIAN 0
  
  #ifdef IN_LIBGCC2
- /* This is to get correct SI and DI modes in libgcc2.c (32 and 64 bits).  */
+ /* To map SI/DI modes in libgcc2.c to HI/SI modes (16 and 32 bits).  */
- #define UNITS_PER_WORD 4
+ #define UNITS_PER_WORD 2
  #else
  /* Width of a word, in units (bytes).  */
  #define UNITS_PER_WORD 1
  #endif
  
  #define POINTER_SIZE 16

*** In File: config/avr.h, Beginning line: 142 ***

  #define INT_TYPE_SIZE (TARGET_INT8 ? 8 : 16)
  #define SHORT_TYPE_SIZE (INT_TYPE_SIZE == 8 ? INT_TYPE_SIZE : 16)
  #define LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 16 : 32)
- #define LONG_LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 32 : 64)
+ #define LONG_LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 32 : 32)
  #define FLOAT_TYPE_SIZE 32
  #define DOUBLE_TYPE_SIZE 32
  #define LONG_DOUBLE_TYPE_SIZE 32
  
  #define DEFAULT_SIGNED_CHAR 1

+ #define SMALL_EH_ENCODEING 1
+
  #define SIZE_TYPE (INT_TYPE_SIZE == 8 ? "long unsigned int" : "unsigned int")
  #define PTRDIFF_TYPE (INT_TYPE_SIZE == 8 ? "long int" :"int")

*** In File: unwind.h, beginning line: 55 ***

  /* @@@ The IA-64 ABI uses a 64-bit word to identify the producer and
     consumer of an exception.  We'll go along with this for now even on
     32-bit machines.  We'll need to provide some other option for
     16-bit machines and for machines with > 8 bits per byte.  */
+ #include "tm.h" /* Fixme: just a temporary hack for small targets.  */
+ #if (SMALL_EH_ENCODEING)
+ typedef unsigned _Unwind_Exception_Class __attribute__((__mode__(__SI__)));
+ #else
  typedef unsigned _Unwind_Exception_Class __attribute__((__mode__(__DI__)));
+ #endif

  /* The unwind interface uses reason codes in several contexts to
     identify the reasons for failures or other actions.  */


*** In File: unwind-pe.h, beginning line: 37 ***

  /* If using C++, references to abort have to be qualified with std::.  */
  #if __cplusplus
  #define __gxx_abort std::abort
  #else
  #define __gxx_abort abort
  #endif

+ #include "tm.h" /* Fixme: just a temporary hack for small targets.  */
+
  /* Pointer encodings, from dwarf2.h.  */
  #define DW_EH_PE_absptr         0x00
  #define DW_EH_PE_omit           0xff


*** In File: unwind-pe.h, beginning line: 184 ***

  static const unsigned char *
  read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
                    const unsigned char *p, _Unwind_Ptr *val)
  {
+ #if (SMALL_EH_ENCODEING) /* Fixme: just a temporary hack for small targets. */
+   union unaligned
+     {
+       void *ptr;
+       unsigned u2 __attribute__ ((mode (QI)));
+       unsigned u4 __attribute__ ((mode (HI)));
+       unsigned u8 __attribute__ ((mode (SI)));
+       signed s2 __attribute__ ((mode (QI)));
+       signed s4 __attribute__ ((mode (HI)));
+       signed s8 __attribute__ ((mode (SI)));
+     } __attribute__((__packed__));
+ #else
    union unaligned
      {
        void *ptr;
        unsigned u2 __attribute__ ((mode (HI)));
        unsigned u4 __attribute__ ((mode (SI)));
        unsigned u8 __attribute__ ((mode (DI)));
        signed s2 __attribute__ ((mode (HI)));
        signed s4 __attribute__ ((mode (SI)));
        signed s8 __attribute__ ((mode (DI)));
      } __attribute__((__packed__));
+ #endif
  
    const union unaligned *u = (const union unaligned *) p;
    _Unwind_Internal_Ptr result;

*** end ***


-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[berndtrog at yahoo dot com]

------- Additional Comments From berndtrog at yahoo dot com  2004-12-27 17:10 -------
Paul, 
I'd like to test your patch in comment #11.
How do I apply it?

Patch says:

patch: **** Only garbage was found in the patch input.

Thanks.

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2004-12-27 18:34 -------
Subject: Re:  [4.0 Regression] libgcc2.h Improperly
 determines required built-in function size requirements.

> From: berndtrog at yahoo dot com <gcc-bugzilla@gcc.gnu.org>
> ------- Additional Comments From berndtrog at yahoo dot com  2004-12-27 17:10
> Paul, 
> I'd like to test your patch in comment #11.
> How do I apply it?
> 
> Patch says:
> 
> patch: **** Only garbage was found in the patch input.

I apologize, what I posed was not a properly formatted patch; but should
be sufficient to hand edit into the few files referenced; from which a
properly formatted one may be generated if desired. (file names given,
search for matching text, + lines added, - lines removed.)




-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[berndtrog at yahoo dot com]

------- Additional Comments From berndtrog at yahoo dot com  2004-12-29 19:38 -------
> Minimal changes required to get avr to build:

OK, building a avr-gcc works with this patch. Thanks!

But I can no longer bootstrap the compiler with this patch (comment #11) applied:

/tmp/HEAD/gcc/gcc/config/i386/i386.h:2931: error: parse error before
'ix86_compare_op0'

(host: i686 linux) 

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[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: 2579 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-01-05 19:47 -------
Hi, 
 
I have the impression that the origin of the bug is not in first line linked to 
a wrong assignment of types in libgcc2. 
 
I doubt whether the problem is not linked to a problem during reload. I.e. I 
assume that reload presently is no longer able to reload any long long objects 
properly for the avr target. This is something that used to work in 3.4.3. and 
seemingly also older revisions of head 4.0 up to about beginning of December. 
 
In order to confirm this, I have used a workaround by commenting out the code 
of the hand full of libgcc2 functions that caused the problems. I.e. I have 
modified them so that they essentially do nothing. You will have to remove 3 
function bodies, IIRC. Of course this will result in compiler output that does 
not execute properly if these functions ever happen to be used. But at compile 
time a problem should never should show up. I.e. using empty functions in 
libgcc2 should never inhibit a proper reload. 
 
After building the compiler this way, I have started the test suite and 
observed about 150 regressions in comparison to 3.4.3. All of them showed up at 
compile time. They all issued an error message of the type 
 
/home/bmh/gnucvs/head/gcc/gcc/testsuite/gcc.c-torture/execute/961122-1.c:11 
internal compiler error: in find_valid_class, at reload.c:719 
 
When checking gcc-3.4.3, I have obtained a PASS for these test cases. Namely 
961122-1.c compiles correctly with gcc-3.4.3. There are quite a number of files 
generating this error. All files that I have investigated had made use of long 
longs. If it helps, I will post a complete list of them. 
c-torture/execute/961122-1.c is a fairly typical example and I'd suggest to 
concentrate on it first, since it is also a fairly short test case. If I'm not 
making a mistake 961122-1.c does also does not make any use of the conversion 
functions that I had to mutilate in order to make avr-gcc bootstrap. 
I also have verified that gcc-3.4.3 indeed has made use of the full DI modes. 
I.e. 3.4.3 has generated code with 8 Byte - objects. 
 
Maybe one should rather look a bit closer at the changes in reload.c .  
 
Yours, 
 
Björn 

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


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[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: 3137 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-01-18 21:40 -------
Indeed the problem seems to be related to a problem during the reload pass. I 
now think, that I have found a solution for the original problem that needs a 
tiny change in the back-end. 
 
DJ Delorie wrote me: 
 
>avr bug - GENERAL_REGS allows $r24 to contain a DImode, but you cannot 
>access the 5th byte of it via a subreg, because HARD_REGNO_MODE_OK 
>doesn't permit QImodes in $r29.  This disqualifies GENERAL_REGS. 
 
Since anyway any useful function using long longs will require the frame 
pointer, there is (in my opinion) no use for DI objects in the upper register 
range. The following patch restricts DI objects to registers with smaller 
indices. When using this patch, I succeed in building the gcc-4.0.0 snapshot 
dating from the 12th of december 04 without problems. This snapshot previously 
did not compile with the symptoms mentioned above. 
 
For a later head revision, unfortunately something else and independent seems 
to be broken. I'll check today's head this evening and report on this, as soon 
as I have analyzed this more in detail. 
 
Patch that needs to be applied to /gcc/config/avr/avr.c 
Reported differences are differences against the 4.0.0-20041212 snapshot. 
 
--- avr.c.old	2005-01-18 22:24:44.942273520 +0100 
+++ avr.c.new	2005-01-18 22:19:19.000000000 +0100 
@@ -5116,40 +5116,47 @@ 
    register number REGNO.  On the enhanced core, anything larger than 
    1 byte must start in even numbered register for "movw" to work 
    (this way we don't have to check for odd registers everywhere).  */ 
  
 int 
 avr_hard_regno_mode_ok (int regno, enum machine_mode mode) 
 { 
   /* Bug workaround: recog.c (peep2_find_free_register) and probably 
      a few other places assume that the frame pointer is a single hard 
      register, so r29 may be allocated and overwrite the high byte of 
      the frame pointer.  Do not allow any value to start in r29.  */ 
   if (regno == REG_Y + 1) 
     return 0; 
  
   /* Reload can use r28:r29 for reload register and for frame pointer 
    in one insn. It's wrong. We must disable it.  */ 
   if (mode != Pmode && reload_in_progress && frame_pointer_required_p () 
       && regno <= REG_Y && (regno + GET_MODE_SIZE (mode)) >= (REG_Y + 1)) 
     return 0; 
  
+  if (mode == DImode) 
+   { if ( (regno < 20) && (!(regno & 1)) )  
+      return 1; 
+     else 
+      return 0; 
+   } 
+ 
   if (mode == QImode) 
     return 1; 
   /*  if (regno < 24 && !AVR_ENHANCED) 
       return 1;*/ 
   return !(regno & 1); 
 } 
  
 /* Returns 1 if X is a valid address for an I/O register of size SIZE 
    (1 or 2).  Used for lds/sts -> in/out optimization.  Add 0x20 to SIZE 
    to check for the lower half of I/O space (for cbi/sbi/sbic/sbis).  */ 
  
 int 
 avr_io_address_p (rtx x, int size) 
 { 
   return (optimize > 0 && GET_CODE (x) == CONST_INT 
 	  && INTVAL (x) >= 0x20 && INTVAL (x) <= 0x60 - size); 
 } 
  
 /* Returns nonzero (bit number + 1) if X, or -X, is a constant power of 2.  */ 
  

-- 


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-21 17:45 -------
There are no 8-bit or 16-bit targets in the primary or secondary platform lists;
removing target milestone.

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


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

[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-01-22 18:28 -------
Subject: Re:  [4.0 Regression] libgcc2.h Improperly
 determines required built-in function size requirements.

Any reason that the milestone was removed vs. moved to 4.1 for tertiary
platforms?


> From: mmitchel at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> 
> ------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-21
> There are no 8-bit or 16-bit targets in the primary or secondary platform
> lists; removing target milestone.
> 
> -- 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>    Target Milestone|4.0.0                       |---
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.




-- 


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

[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
   Target Milestone|---                         |4.1.0


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

[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-13 15:04 -------
Closing as fixed, then. Paul, you can open a new enhancement PR to keep track 
of the libgcc problem.

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


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

[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-03-14 14:25 -------
Subject: Re:  [4.0/4.1 Regression] libgcc2.h
 Improperly determines required built-in function size requirements.

> ------- Additional Comments From giovannibajo at libero dot it  2005-03-13
> Closing as fixed, then. Paul, you can open a new enhancement PR to keep track
> of the libgcc problem.

Yup, that's fine; still trying to recover from some of the recent changes
which seem to have mucked up the pieces what I had working; so unfortunately
have taken a few steps back. thanks -paul- 




-- 


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