>> please keep in mind that -Wfoo does reflect the ideas of the GNU people
>> regarding *proper* code. the warnings themselves are sometimes wrong,
>> because they complain about perfectly correct code.
I attempted to get the gcc people to improve this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
On Tue May 31 11, Dimitry Andric wrote:
> On 2011-05-31 16:39, Alexander Best wrote:
> ...
> >...which leads me to the conclusion that -O should be set when DEBUG was
> >defined: an all ARCHS.
> >
> >right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
> >kernel contains DDB,
On 05/31/2011 07:39, Alexander Best wrote:
...which leads me to the conclusion that -O should be set when DEBUG was
defined: an all ARCHS.
+1
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of know
On May 31, 2011, at 11:45 AM, Dimitry Andric wrote:
> On 2011-05-31 17:26, Alexander Best wrote:
> ...
>> so how about the following patch?
>
> Could you please try to not mix spacing and style changes with
> functional changes in this patch? It makes it more difficult to review.
+1
__
On 2011-05-31 17:26, Alexander Best wrote:
...
so how about the following patch?
Could you please try to not mix spacing and style changes with
functional changes in this patch? It makes it more difficult to review.
___
freebsd-hackers@freebsd.org ma
On 2011-05-31 16:39, Alexander Best wrote:
...
...which leads me to the conclusion that -O should be set when DEBUG was
defined: an all ARCHS.
right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn'
On Tue May 31 11, Alexander Best wrote:
> On Tue May 31 11, Garrett Cooper wrote:
> > On May 31, 2011, at 3:46 AM, Alexander Best wrote:
> >
> > > On Tue May 31 11, Dimitry Andric wrote:
> > >> On 2011-05-31 11:57, Alexander Best wrote:
> > >> ...
> > > however i've often read messages - most
On Tue May 31 11, Garrett Cooper wrote:
> On May 31, 2011, at 3:46 AM, Alexander Best wrote:
>
> > On Tue May 31 11, Dimitry Andric wrote:
> >> On 2011-05-31 11:57, Alexander Best wrote:
> >> ...
> > however i've often read messages - mostly by bruce evans - claiming that
> > anything gre
On Tue, 31 May 2011, Alexander Best wrote:
On Mon May 30 11, Dieter BSD wrote:
Chris writes:
Ports need attention. The warnings I get there are frightening.
I find it comforting that they're just that: warnings.
How do they frighten you?
High quality code does not have any warnings.
The
On May 31, 2011, at 3:46 AM, Alexander Best wrote:
> On Tue May 31 11, Dimitry Andric wrote:
>> On 2011-05-31 11:57, Alexander Best wrote:
>> ...
> however i've often read messages - mostly by bruce evans - claiming that
> anything greater than -O will in fact decrease a kernel's ability
On Mon May 30 11, Dieter BSD wrote:
> Chris writes:
> >> Ports need attention. The warnings I get there are frightening.
> >
> > I find it comforting that they're just that: warnings.
> >
> > How do they frighten you?
>
> High quality code does not have any warnings.
>
> The most frightening thin
On Tue May 31 11, Dimitry Andric wrote:
> On 2011-05-31 11:57, Alexander Best wrote:
> ...
> >>>however i've often read messages - mostly by bruce evans - claiming that
> >>>anything greater than -O will in fact decrease a kernel's ability to be
> >>>debugged just as well as a kernel with -O.
> >>T
On 2011-05-31 11:57, Alexander Best wrote:
...
however i've often read messages - mostly by bruce evans - claiming that
anything greater than -O will in fact decrease a kernel's ability to be
debugged just as well as a kernel with -O.
The critical option when -O2 is used is -fno-omit-frame-point
On Sat May 28 11, Bruce Cran wrote:
> On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> >
> > well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> > compiled with -O2 frename-registers can be debugged the same way as one with
> > -O? if that is the case: su
Chris writes:
>> Ports need attention. The warnings I get there are frightening.
>
> I find it comforting that they're just that: warnings.
>
> How do they frighten you?
High quality code does not have any warnings.
The most frightening thing is the attitute that "They're just warnings,
so I'll i
On Mon May 30 11, Dieter BSD wrote:
> > maybe we find some nice -Wwarning options which are reasonable
> > to have
>
> -Wmissing-declarations
> -Wimplicit
>
> FreeBSD's gcc doesn't seem to have -Wcoercion ???
> Bugzilla indicates that it was added years ago (2006?).
-Wcoercion seems to have on
On 30 May 2011 18:44, Dieter BSD wrote:
>> maybe we find some nice -Wwarning options which are reasonable
>> to have
>
> -Wmissing-declarations
> -Wimplicit
>
> FreeBSD's gcc doesn't seem to have -Wcoercion ???
> Bugzilla indicates that it was added years ago (2006?).
>
> It would be really real
> maybe we find some nice -Wwarning options which are reasonable
> to have
-Wmissing-declarations
-Wimplicit
FreeBSD's gcc doesn't seem to have -Wcoercion ???
Bugzilla indicates that it was added years ago (2006?).
It would be really really nice if -static worked on (nearly) everything.
> and
On Sat May 28 11, Alexander Best wrote:
> On Sat May 28 11, Bruce Cran wrote:
> > On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> > >
> > > well i'm not an expert on this. but are we 100% sure that a kernel on
> > > amd64
> > > compiled with -O2 frename-registers can be debugged
On Sat May 28 11, Bruce Cran wrote:
> On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> >
> > well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> > compiled with -O2 frename-registers can be debugged the same way as one with
> > -O? if that is the case: su
On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
>
> well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> compiled with -O2 frename-registers can be debugged the same way as one with
> -O? if that is the case: sure...-O2 is fine. ;)
>
> however i've often r
On Sat May 28 11, Alexander Best wrote:
> On Sat May 28 11, Pan Tsu wrote:
> > Alexander Best writes:
> >
> > > On Fri May 27 11, Alexander Best wrote:
> > >> On Fri May 27 11, Warner Losh wrote:
> > >> > These look generally good. Just one thing I had a question on:
> > >> >
> > >> > #
> > >>
On Sat May 28 11, Pan Tsu wrote:
> Alexander Best writes:
>
> > On Fri May 27 11, Alexander Best wrote:
> >> On Fri May 27 11, Warner Losh wrote:
> >> > These look generally good. Just one thing I had a question on:
> >> >
> >> > #
> >> > +# Enable FreeBSD kernel-specific printf format specifi
Alexander Best writes:
> On Fri May 27 11, Alexander Best wrote:
>> On Fri May 27 11, Warner Losh wrote:
>> > These look generally good. Just one thing I had a question on:
>> >
>> > #
>> > +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct
>> > gcc to
>> > +# enable so
On Fri May 27 11, Warner Losh wrote:
>
> On May 27, 2011, at 12:14 PM, Alexander Best wrote:
>
> > On Fri May 27 11, Warner Losh wrote:
> >> These look generally good. Just one thing I had a question on:
> >>
> >> #
> >> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct
On May 27, 2011, at 12:14 PM, Alexander Best wrote:
> On Fri May 27 11, Warner Losh wrote:
>> These look generally good. Just one thing I had a question on:
>>
>> #
>> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct
>> gcc to
>> +# enable some diagnostics, which make
On Fri May 27 11, Alexander Best wrote:
> On Fri May 27 11, Warner Losh wrote:
> > These look generally good. Just one thing I had a question on:
> >
> > #
> > +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct
> > gcc to
> > +# enable some diagnostics, which make it easi
On Fri May 27 11, Warner Losh wrote:
> These look generally good. Just one thing I had a question on:
>
> #
> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc
> to
> +# enable some diagnostics, which make it easier to pinpoint tinderbox
> failures.
> +CFLAGS+=
These look generally good. Just one thing I had a question on:
#
+# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc to
+# enable some diagnostics, which make it easier to pinpoint tinderbox failures.
+CFLAGS+= -fformat-extensions -fdiagnostics-show-option
+
Does
hi there,
i would like to hear people's opinion regarding the following patch. it
features the following semantic changes:
1) -W is now called -Wextra
2) move -fformat-extensions and -fdiagnostics-show-option out of CWARNFLAGS,
since they aren't really warnings. this will now let anybody use c
30 matches
Mail list logo
