You should really file a PR about this.
Doug
--
This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Fri, Aug 22, 2003 at 06:59:20PM -0500, Loren James Rittle wrote:
> Trying to consider how to best pull important differences back into
> the FSF tree. Will this be true for all FreeBSD systems going forward?
>
> < %{!dynamic-linker:-dynamic-linker /usr/libexec/ld-elf.so.1}}
> ---
> >
Alexander Kabaev wrote:
>> I am about to import an official GCC 3.3.1-release into our
>> source tree. Please hold your updates until 'all clear' message
>> is posted.
> Done.
Alex, nice. Thank you for making -Wno-system-headers work in the
system compiler (henceforth, users that want to compile
On Thu, Aug 21, 2003 at 09:40:42PM -0700, Alexander Kabaev wrote:
> On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote:
> > I am about to import an official GCC 3.3.1-release into our
> > source tree. Please hold your updates until 'all clear' message
> > is posted.
>
> Done.
>
Does
On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote:
> I am about to import an official GCC 3.3.1-release into our
> source tree. Please hold your updates until 'all clear' message
> is posted.
Done.
___
[EMAIL PROTECTED] mailing list
http:/
On Tue, Aug 19, 2003 at 06:39:13PM -0700, David O'Brien wrote:
> On Tue, Aug 19, 2003 at 02:15:03PM -0700, Kris Kennaway wrote:
> > > I see an ICE building the math/R-letter port on -current (x86) from
> > > late last week.
> > >
> > > % gcc -v
> > > Using built-in specs.
> > > Configured with: Fr
On Tue, Aug 19, 2003 at 02:15:03PM -0700, Kris Kennaway wrote:
> > I see an ICE building the math/R-letter port on -current (x86) from
> > late last week.
> >
> > % gcc -v
> > Using built-in specs.
> > Configured with: FreeBSD/i386 system compiler
> > Thread model: posix
> > gcc version 3.3.1 [Fre
On Tue, Aug 19, 2003 at 05:08:44PM -0400, Andrew Gallatin wrote:
>
> I see an ICE building the math/R-letter port on -current (x86) from
> late last week.
>
> % gcc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.3.1 [FreeBSD] 20030
David Leimbach wrote:
> >Gcc needs a #pragma to disable specific warnings as a one-shot.
> >
> >This was discussed in detail on the GCC mailing list.
>
> True... but I don't think I was talking about a one-shot disabling
> of the message.
>
> I was thinking more about how a compliant C++ compiler
On Monday, July 14, 2003, at 01:33PM, Terry Lambert <[EMAIL PROTECTED]> wrote:
>David Leimbach wrote:
>> This is a good policy in general, however, one could easily argue that
>> what is trying to be determined with signedness and such being
>> less-than-compared
>> to 0 isn't really a big deal
David Leimbach wrote:
> This is a good policy in general, however, one could easily argue that
> what is trying to be determined with signedness and such being
> less-than-compared
> to 0 isn't really a big deal and possibly the only way to implement this
> numeric_limits::digits thing without any
On Sun, 13 Jul 2003, Erik Trulsson wrote:
> On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote:
> > You keep saying this... where is this "must behave as two's compliment
> > stated?"
> >
> > >(unsigned int) -1 == 0x (assuming 32-bit int).
> >
> > or with a valid one's com
On Sun, 13 Jul 2003, Marcel Moolenaar wrote:
> On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote:
> >
> > This is a good policy in general, however, one could easily argue that
> > what
> > is trying to be determined with signedness and such being
> > less-than-compared
> > to 0 isn'
On Sun, Jul 13, 2003 at 01:48:38PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> David Leimbach <[EMAIL PROTECTED]> writes:
> : So for the one way conversion of signed to unsigned it will behave like
> : 2's compliment
> : all the time. What about back to signed?
>
On Sun, Jul 13, 2003 at 02:28:38PM -0500, David Leimbach wrote:
> >
> >C doesn't require two's compliment, but it encourages it.
> >
> >If you take a signed value and convert it to the corresponding
> >unsigned type , the result must be equal modulo 2^N to the original
> >value (where N is the num
In message: <[EMAIL PROTECTED]>
David Leimbach <[EMAIL PROTECTED]> writes:
: So for the one way conversion of signed to unsigned it will behave like
: 2's compliment
: all the time. What about back to signed?
Same way.
It will be reduced by the maximum value of the range plus one to
In message: <[EMAIL PROTECTED]>
David Leimbach <[EMAIL PROTECTED]> writes:
:
: On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote:
:
: > In message: <[EMAIL PROTECTED]>
: > Jilles Tjoelker <[EMAIL PROTECTED]> writes:
: > : The compiler moans about (T)(-1) >= 0 as we
In message: <[EMAIL PROTECTED]>
David Leimbach <[EMAIL PROTECTED]> writes:
: You keep saying this... where is this "must behave as two's compliment
: stated?"
Read the fine print on the signed to unsigned conversion and you find
that it must be done modulo 2^N. Also, I never stated t
C doesn't require two's compliment, but it encourages it.
If you take a signed value and convert it to the corresponding
unsigned type , the result must be equal modulo 2^N to the original
value (where N is the number of bits in the unsigned type. (Ignoring
any padding bits.)) (Actually it is mod
On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote:
>
> On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote:
>
> >: > 134 #define __glibcpp_signed(T) ((T)(-1) < 0)
> >: #define __glibcpp_signed(T) (!((T)(-1) > 0))
> >
> >Why not the simpler:
> >
> >#define __glibcpp_
On Sun, Jul 13, 2003 at 01:25:45PM -0500, David Leimbach wrote:
>
> On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote:
>
> >In message: <[EMAIL PROTECTED]>
> >Jilles Tjoelker <[EMAIL PROTECTED]> writes:
> >: The compiler moans about (T)(-1) >= 0 as well. Is the assumption that
On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote:
: > 134 #define __glibcpp_signed(T) ((T)(-1) < 0)
: #define __glibcpp_signed(T) (!((T)(-1) > 0))
Why not the simpler:
#define __glibcpp_signed(T) ((T)(-1) <= 0)
that way we have an overlap on the range of the two types, s
On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote:
>
> This is a good policy in general, however, one could easily argue that
> what
> is trying to be determined with signedness and such being
> less-than-compared
> to 0 isn't really a big deal and possibly the only way to implemen
On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Jilles Tjoelker <[EMAIL PROTECTED]> writes:
: The compiler moans about (T)(-1) >= 0 as well. Is the assumption that
: (unsigned type)(-1) is never zero valid?
yes. There are no known machines wh
: > 134 #define __glibcpp_signed(T) ((T)(-1) < 0)
: #define __glibcpp_signed(T) (!((T)(-1) > 0))
Why not the simpler:
#define __glibcpp_signed(T) ((T)(-1) <= 0)
that way we have an overlap on the range of the two types, so we won't
get a warning. We know for a fact that -1 != 0
In message: <[EMAIL PROTECTED]>
Jilles Tjoelker <[EMAIL PROTECTED]> writes:
: The compiler moans about (T)(-1) >= 0 as well. Is the assumption that
: (unsigned type)(-1) is never zero valid?
yes. There are no known machines where -1 == 0 for types of different
signs. Further, the C s
On Sun, Jul 13, 2003 at 12:43:31AM -0400, Craig Rodrigues wrote:
> The warnings seemed to be caused by this code in
> /usr/include/c++/3.3/limits:
> =
> 630 static const int digits = __glibcpp_digits (unsigned int);
On Sunday, July 13, 2003, at 8:13AM, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Craig Rodrigues <[EMAIL PROTECTED]> writes:
: I think that this is a FreeBSD issue. I compiled
: the same file under Linux, with a GCC 3.3.1 checked out on 7/11
: and did not encounter this warn
On Saturday, July 12, 2003, at 11:05PM, Alexander Kabaev wrote:
On Sat, 12 Jul 2003 23:13:12 -0400
Craig Rodrigues <[EMAIL PROTECTED]> wrote:
I am guessing that the C preprocessor does not think that it is
in a system header, and thus prints out the warning.
We specifically disable automatic warni
In message: <[EMAIL PROTECTED]>
Alexander Kabaev <[EMAIL PROTECTED]> writes:
: Short of fixing offending files in FSF libstdc++ or turning warning
: suppression back on for standard C++ include files selectively, I have
: no suggestion.
In the past I know that FSF has accepted patches
In message: <[EMAIL PROTECTED]>
Craig Rodrigues <[EMAIL PROTECTED]> writes:
: I think that this is a FreeBSD issue. I compiled
: the same file under Linux, with a GCC 3.3.1 checked out on 7/11
: and did not encounter this warning.
keep in mind that on linux the -wno-system-headers is
On Sun, Jul 13, 2003 at 12:05:59AM -0400, Alexander Kabaev wrote:
> On Sat, 12 Jul 2003 23:13:12 -0400
> Craig Rodrigues <[EMAIL PROTECTED]> wrote:
>
> > I am guessing that the C preprocessor does not think that it is
> > in a system header, and thus prints out the warning.
>
> We specifically di
On Sat, 12 Jul 2003 23:13:12 -0400
Craig Rodrigues <[EMAIL PROTECTED]> wrote:
> I am guessing that the C preprocessor does not think that it is
> in a system header, and thus prints out the warning.
We specifically disable automatic warning suppression for system
headers, because we _want_ to kno
Hi,
I think that this is a FreeBSD issue. I compiled
the same file under Linux, with a GCC 3.3.1 checked out on 7/11
and did not encounter this warning.
I think you hit it on the head.
I looked in the source code of gcc and found this:
/usr/src/contrib/gcc/c-common.c
2597 case LT_
On Sat, Jul 12, 2003 at 09:50:21PM -0500, David Leimbach wrote:
> Heh that's because the offending macro __glibcpp_digits calls
> __glibcpp_signed (T)
> on an unsigned type which does a < compareison.
>
> std::numeric_limits ::digits on a 32bit FBSD will yield 31
> because its
> got 31 bits for
Heh that's because the offending macro __glibcpp_digits calls
__glibcpp_signed (T)
on an unsigned type which does a < compareison.
std::numeric_limits ::digits on a 32bit FBSD will yield 31
because its
got 31 bits for magnitude.
Unfortunately the way it seems to go about calculating that stuff
On Sat, Jul 12, 2003 at 07:45:07PM +0400, Sergey Matveychuk wrote:
> Alexander Kabaev wrote:
> >On Sat, 12 Jul 2003 06:08:57 +0400
> >Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Don't forget bump __FreeBSD_version. :)
> >>
> >
> >What for? Bumped __FreeBSD_cc_version is enough.
> >
>
Alexander Kabaev wrote:
On Sat, 12 Jul 2003 06:08:57 +0400
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
Don't forget bump __FreeBSD_version. :)
What for? Bumped __FreeBSD_cc_version is enough.
The ports system use it. How can we check is gcc changed?
!defined(OSVERSION)
.if exists(/sbin/sysctl)
On Sat, 12 Jul 2003 06:08:57 +0400
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:
> Don't forget bump __FreeBSD_version. :)
>
What for? Bumped __FreeBSD_cc_version is enough.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/fre
39 matches
Mail list logo
