[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- 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
[Bug middle-end/18887] [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 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.
-- 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.
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-02-28 21:49 --- 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 -- 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.
--- 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')? -- 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.
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:10 --- 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. -- 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.
--- Additional Comments From schlie at comcast dot net 2005-02-28 22:38 --- 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.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
