Bug 18887 - [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.
Summary: [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in functi...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P3 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 18941 18988 (view as bug list)
Depends on:
Blocks: 19378
  Show dependency treegraph
 
Reported: 2004-12-08 13:04 UTC by Paul Schlie
Modified: 2005-03-13 15:04 UTC (History)
6 users (show)

See Also:
Host: any
Target: 8/16 bit targets
Build: any
Known to work: 3.4.2
Known to fail: 4.0.0
Last reconfirmed: 2004-12-11 16:37:47


Attachments
unwind-pe.h (2.50 KB, application/octet-stream)
2004-12-29 20:22 UTC, Paul Schlie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Schlie 2004-12-08 13:04:06 UTC
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 %.
Comment 1 Andrew Pinski 2004-12-08 14:36:33 UTC
Is this really a bug as almost all 8/16bit targets provide their own libgcc1?
Comment 2 Paul Schlie 2004-12-08 15:24:11 UTC
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?]



Comment 3 Paul Schlie 2004-12-08 20:25:05 UTC
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



Comment 4 Giovanni Bajo 2004-12-11 16:37:47 UTC
Given that this breaks bootstrap of the AVR platform, I'm marking this as a 
regression. Paul, go ahead and submit your patch.
Comment 5 Andrew Pinski 2004-12-11 17:58:32 UTC
P3 because almost all of the embedded targets (and especially the 8/16bit ones) are not primary 
targets.
Comment 6 Andrew Pinski 2004-12-12 03:09:38 UTC
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.
Comment 7 Bernardo Innocenti 2004-12-12 13:52:07 UTC
*** Bug 18941 has been marked as a duplicate of this bug. ***
Comment 8 Bernardo Innocenti 2004-12-12 14:11:51 UTC
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,
Comment 9 Bernardo Innocenti 2004-12-12 14:22:09 UTC
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.
Comment 10 Andrew Pinski 2004-12-14 16:40:36 UTC
*** Bug 18988 has been marked as a duplicate of this bug. ***
Comment 11 Paul Schlie 2004-12-21 20:19:06 UTC
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 ***
Comment 12 berndtrog 2004-12-27 17:10:37 UTC
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.
Comment 13 Paul Schlie 2004-12-27 18:34:35 UTC
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.)


Comment 14 berndtrog 2004-12-29 19:38:57 UTC
> 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) 
Comment 15 Paul Schlie 2004-12-29 20:22:13 UTC
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>
> 
> 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)

The only possibility is that i386.h has some odd C code included by the
newly added #included tm.h, in unwind.h unwind_pe.h; as no other changes
could affect anything?




Comment 16 Paul Schlie 2004-12-29 20:22:15 UTC
Created attachment 7842 [details]
unwind-pe.h
Comment 17 Björn Haase 2005-01-05 19:47:58 UTC
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 
Comment 18 Björn Haase 2005-01-18 21:40:02 UTC
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.  */ 
  
Comment 19 Mark Mitchell 2005-01-21 17:45:34 UTC
There are no 8-bit or 16-bit targets in the primary or secondary platform lists;
removing target milestone.
Comment 20 Paul Schlie 2005-01-22 18:28:38 UTC
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.


Comment 21 Björn Haase 2005-02-28 21:49:27 UTC
Hi,  
 
since this bug has been fixed by a patch of Roger Sayles a couple of weeks 
ago, I suggest to mark it as "fixed". 
 
Yours, 
 
Björn 
 
Comment 22 Paul Schlie 2005-02-28 22:02:32 UTC
(In reply to comment #21)
> Hi,  
>  
> since this bug has been fixed by a patch of Roger Sayles a couple of weeks 
> ago, I suggest to mark it as "fixed". 

It's true that the original failure mode, which nessesitated removing 64-bit long longs
has been fixed, but observe that none the less; libgcc2.h still improperly determines
built-in function types, if long-long types are not declared as being supported by the
target. (the catch 22 is that one can't show a regression against an exiting target,
because exiting targets would not build without 64-bit type support, therefore the
only means to demonstraite it is to intentially remove such type support from an exsiting
target, which should otherwise build fine, but wont')?
Comment 23 Eric Weddington 2005-02-28 22:10:43 UTC
Subject: Re:  [4.0/4.1 Regression] libgcc2.h Improperly
 determines required built-in function size requirements.

schlie at comcast dot net wrote:

>------- Additional Comments From schlie at comcast dot net  2005-02-28 22:02 -------
>(In reply to comment #21)
>  
>
>>Hi,  
>> 
>>since this bug has been fixed by a patch of Roger Sayles a couple of weeks 
>>ago, I suggest to mark it as "fixed". 
>>    
>>
>
>It's true that the original failure mode, which nessesitated removing 64-bit long longs
>has been fixed, but observe that none the less; libgcc2.h still improperly determines
>built-in function types, if long-long types are not declared as being supported by the
>target. (the catch 22 is that one can't show a regression against an exiting target,
>because exiting targets would not build without 64-bit type support, therefore the
>only means to demonstraite it is to intentially remove such type support from an exsiting
>target, which should otherwise build fine, but wont')?
>
>  
>
We've already gone over this. If you want to modify the sources to not 
declare the long long type for the AVR, fine, but that is on your 
experimental sources.
See the previous discussion about this on bug #
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143>
Please stop rehashing the same stuff in bug reports.

If the original failure is fixed, then close the bug report.
If there are different failures, then open up new bug reports, one per 
failure.


Comment 24 Paul Schlie 2005-02-28 22:38:11 UTC
Subject: Re:  [4.0/4.1 Regression] libgcc2.h
 Improperly determines required built-in function size requirements.

> - Additional Comments From ericw at evcohs dot com  2005-02-28 22:10
> We've already gone over this. If you want to modify the sources to
> not declare the long long type for the AVR, fine, but that is on your
> experimental sources.

I agree that this should be closed, as it was originally specific
to the avr;  but please try to understand the difference between
demonstrating a general problem using an existing port as a baseline,
and the stating the port used to demonstrate the general problem has
a bug, which is not what was being claimed. (As I do plan to use the
avr port as a general small target baseline in likely future general
bug reports in this way, as it's the most reliable way to demonstrate
the effect of a single parameter in an otherwise known good port.)



Comment 25 Giovanni Bajo 2005-03-13 15:04:17 UTC
Closing as fixed, then. Paul, you can open a new enhancement PR to keep track 
of the libgcc problem.
Comment 26 Paul Schlie 2005-03-14 14:25:10 UTC
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-