[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-10 15:32:40 UTC --- Hosting/building GCC on a platform without a 64bit integer type is not really supported.
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-15 15:39 --- What happened to this patch? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Comment #9 from schlie at comcast dot net 2007-11-16 02:35 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. submitted, a long while ago; but honestly haven't been tracking things lately. From: manu at gcc dot gnu dot org [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 15 Nov 2007 15:39:19 - To: [EMAIL PROTECTED] Subject: [Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC. --- Comment #8 from manu at gcc dot gnu dot org 2007-11-15 15:39 --- What happened to this patch? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29 00:25 --- Note all patches should always goto [EMAIL PROTECTED] -- What|Removed |Added Severity|normal |enhancement Component|bootstrap |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29 00:26 --- Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked (I think it is defined by the dwarf-2 standard). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From schlie at comcast dot net 2005-03-29 00:28 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. Note all patches should always goto gcc-patches ok, just sent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From schlie at comcast dot net 2005-03-29 01:14 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked (I think it is defined by the dwarf-2 standard). - From the best I can tell reviewing the standard, it seems fully compatible to limit the target's unwind data type size, to the largest data type it supports; as although a 64-bit data type is defined by the standard, neither a host application or target could validly send, request data sized larger than the largest type defined as supported by the target; nor are large data types required for communicating smaller data type values, as data access is byte not unwind-word offset/size oriented. (so it seems fully compatible from the best I can tell?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From schlie at comcast dot net 2005-03-29 02:09 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked (I think it is defined by the dwarf-2 standard). - From the best I can tell reviewing the standard, it seems fully compatible to limit the target's unwind data type size, to the largest data type it supports; as although a 64-bit data type is defined by the standard, neither a host application or target could validly send, request data sized larger than the largest type defined as supported by the target; nor are large data types required for communicating smaller data type values, as data access is byte not unwind-word offset/size oriented. (so it seems fully compatible from the best I can tell?) - Actually there may be a problem, as I did notice that the stabs data section size was affected by this change, which wouldn't have guessed to be affected by the size of the target's run-time unwind word data size? It seems that GCC may be presuming that the static debug data (which is for debugger reference) is using the target's unwind word size; which is wrong they are unrelated to each other, although may be the same. Static debug data should be based on it's required encoding specification, and have nothing to do with a target's run-time unwind implementation. (I'll take a closer look to try to figure out why one is affecting the other. However just to double check, is there any reason that a target needs to support a data type size that it never references, although is statically encoded by the linker into it's debug data section?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Additional Comments From schlie at comcast dot net 2005-03-29 03:42 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. Static debug data should be based on it's required encoding specification, and have nothing to do with a target's run-time unwind implementation. (I'll take a closer look to try to figure out why one is affecting the other. However just to double check, is there any reason that a target needs to support a data type size that it never references, although is statically encoded by the linker into it's debug data section?) - what appears to be happening is unrelated to the unwind word size; the stabs data section size is changing when the target's long long size is reduced to the size of a long, thereby requiring less bytes to represent leb128 encoded min/max signed/unsigned long long date definitions for the target; which seems correct; and not related to reducing small target's unwind word size which should not effect it's dwarf compliance. (so all seems ok) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
