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]"
Hi!
[3.3 regression] miscompiles XDM-AUTHORIZATION-1 key generation and/or
validation in XFree86 at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11366
[3.3/3.4 regression] loop miscompiled on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11319
PATCH:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/
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 (hencefo
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
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
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.
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
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
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] 20030711 (prerelease)
cc -I../../src/extra/pcre -I. -I../../src/include -I../../src/in
Alexander Kabaev wrote:
> On Thu, 17 Jul 2003 14:02:20 -0700
> Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >
> > Sorry, I missed the patch in your email. I'm not certain about your
> > approach...can someone who understands the issues comment on it?
>
> I'd rather see all varargs.h consumers be co
On Thu, Jul 17, 2003 at 11:37:17PM -0400, Alexander Kabaev wrote:
> On Thu, 17 Jul 2003 14:02:20 -0700
> Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >
> > Sorry, I missed the patch in your email. I'm not certain about your
> > approach...can someone who understands the issues comment on it?
> >
>
On Thu, 17 Jul 2003 14:02:20 -0700
Kris Kennaway <[EMAIL PROTECTED]> wrote:
>
> Sorry, I missed the patch in your email. I'm not certain about your
> approach...can someone who understands the issues comment on it?
>
> Kris
>
I'd rather see all varargs.h consumers be converted to stdarg.h. Old
On Thu, Jul 17, 2003 at 01:59:46PM -0700, Kris Kennaway wrote:
> On Fri, Jul 18, 2003 at 12:11:39AM +0900, Motoyuki Konno wrote:
> > Add Cc: to -current list.
> >
> >
> > This seems to be "varargs.h" problem. It seems that all C source
> > which u
On Fri, Jul 18, 2003 at 12:11:39AM +0900, Motoyuki Konno wrote:
> Add Cc: to -current list.
>
>
> This seems to be "varargs.h" problem. It seems that all C source
> which use varargs.h and va_dcl become error on GCC 3.3.1 system.
This is a known problem. Can
Add Cc: to -current list.
This seems to be "varargs.h" problem. It seems that all C source
which use varargs.h and va_dcl become error on GCC 3.3.1 system.
Please try compiling following varargs.h sample program.
#include
void test(va_alist)
va_dcl
{
va_list args;
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
Jens Rehsack wrote:
> Hi,
>
> I tried to update a machine which will become a webserver in
> near future. I received following error in buildkernel:
>
> [...]
>
> cc -c -O -pipe -march=pentium4 -Wall \
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
> -Wmissing-prototypes -Wpoin
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-W
Jens Rehsack wrote:
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-W
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 en
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-syste
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
ginal gcc c++
> header file or has
> it been tweaked?]
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 looked in the source code of gcc and found this:
/usr/src/contri
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.
> >
>
Hi,
If I compile the following program:
#include
int main(int argc, char *argv[] { return 0; }
with the following flags:
g++ -W -Wall b.cc
I get lots of warnings that did not appear in GCC 3.2:
In file included from /usr/include/c++/3.3/bits/locale_facets.tcc:43,
from /usr/
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
Don't forget bump __FreeBSD_version. :)
Sem.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
This is HEADS UP form people who haven't upfdated theri systems yet.
Please hold your updates as there are reports of a kernel being broken
with symptoms I haven't seen on my testing machine. Either I mismerged
something or something else did go wrong. I am lookign into this right
now and will keep
On Thu, Jul 10, 2003 at 08:15:48PM -0700, Alexander Kabaev wrote:
> I'll be importing a GCC 3.3.1 snapshot in a couple of minutes.
> Please hold your updates until I post 'all clear' message.
OK, things are in somewhat working shape back again. The world/kernel
builds on
I'll be importing a GCC 3.3.1 snapshot in a couple of minutes.
Please hold your updates until I post 'all clear' message.
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
Due to unforeseen circumstances the new compiler import scheduled
for today is not going to happen. I will complete it tomorrow once
yet another round of testing is complete.
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org
58 matches
Mail list logo
