Jeff Law writes:
> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>> Andrew Haley writes:
>>
>>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
With this situation at hand, I wonder whether it's a good idea to keep
maybe-uninitialized included in -Wall. Projects which have been using
Tom Tromey writes:
> gdb only enables it for the development branch, not for releases. If
> you're building from CVS you're expected to know how to either fix
> these problems or disable -Werror. Typically the fix is trivial; if
> you look through the archives you'll see fixes along these lines
On Tue, Jul 9, 2013 at 4:57 PM, Jeff Law wrote:
> I personally like -Wall -Werror. While we do run into false positives and
> the set of false positives does change from release to release as a result
> of optimizations, I believe there's been an overall improvement in the
> quality of the codeb
On Mon, Jul 08, 2013 at 09:42:14PM +0200, Oleg Endo wrote:
> On Mon, 2013-07-08 at 16:12 +0200, Ondřej Bílka wrote:
> > On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote:
> > > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote:
> > >
> > > - http://www.ddj.com/articles/1997/9701/
On 10 July 2013 15:00, Ondřej Bílka wrote:
>>
> I prefer fix issues one class at time. I added script that checks dead
> links by extracting http addresses from sources and checking them by curl -f.
> It found:
>
> $ ./stylepp/script/stylepp_warn_dead_link
>
> Dead link: http://anubis.dkuug.dk/jtc1
Andrew Haley writes:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced to
>> investigate n
On Wed, 2013-07-10 at 16:00 +0200, Ondřej Bílka wrote:
> Dead link: http://fedora.linux.duke.edu/fc1_x86_64
FWIW, this link occurs in historical notes at the top of these files:
zlib/contrib/inflate86/inffas86.c
zlib/contrib/masmx64/inffas8664.c
dated Dec-29-2003 describing specific testing d
On Jul 10, 2013, at 10:42 AM, Andi Kleen wrote:
> Andrew Haley writes:
>
>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>> With this situation at hand, I wonder whether it's a good idea to keep
>>> maybe-uninitialized included in -Wall. Projects which have been using
>>> "-Wall -Werror" succ
On 10 July 2013 15:47, David Malcolm wrote:
> On Wed, 2013-07-10 at 16:00 +0200, Ondřej Bílka wrote:
>
>> Dead link: http://fedora.linux.duke.edu/fc1_x86_64
>
> FWIW, this link occurs in historical notes at the top of these files:
> zlib/contrib/inflate86/inffas86.c
> zlib/contrib/masmx64/inffa
On Wed, Jul 10, 2013 at 04:01:54PM +0100, Jonathan Wakely wrote:
> On 10 July 2013 15:47, David Malcolm wrote:
> > On Wed, 2013-07-10 at 16:00 +0200, Ondřej Bílka wrote:
> >
> >> Dead link: http://fedora.linux.duke.edu/fc1_x86_64
> >
> > FWIW, this link occurs in historical notes at the top of thes
On 07/10/2013 04:51 AM, Andreas Arnez wrote:
Jeff Law writes:
OK, I may be biased, because I have *only* seen false positives with
this warning so far. Others may have made better experience with it.
It's found numerous bugs across many projects. The reduction in bug
reports against GCC whic
On Wed, Jul 10, 2013 at 9:42 AM, Andi Kleen wrote:
> Andrew Haley writes:
>
>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>> With this situation at hand, I wonder whether it's a good idea to keep
>>> maybe-uninitialized included in -Wall. Projects which have been using
>>> "-Wall -Werror" suc
> No. People expect that -Werror turns warnings into errors.
> That is what we have documented for years.
> Starting to special case these things is a royal road to confusion,
> and a slippery slope.
Ok, I will keep removing -Werrors from Makefiles then.
FWIW basically -Werror -Wall defines a co
Michael Matz wrote:
[...]
> As you didn't adjust any cost I would guess the high value comes from the
> default implementation of address_cost, which simply uses arithmetic cost,
> and the MULT in there is quite expensive by default.
>
> See TARGET_ADDRESS_COST in several ports.
Oddly, TARGET_A
On 10 July 2013 16:22, Ondřej Bílka wrote:
>> Thanks. Ondřej, as stated a few times now, anything in zlib,
>> boehm-gc, etc. is maintained outside the GCC project. Do you have any
>> way to filter out certain directories from being checked by your
>> scripts?
>
> I have (place .indent.off file to
On 07/10/2013 05:11 PM, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
I could not have put it any better.
Andrew.
On 10 July 2013 17:11, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
That's a very nice way to put it.
On Wed, Jul 10, 2013 at 07:42:55AM -0700, Andi Kleen wrote:
> Andrew Haley writes:
>
> > On 07/09/2013 12:59 PM, Andreas Arnez wrote:
> >> With this situation at hand, I wonder whether it's a good idea to keep
> >> maybe-uninitialized included in -Wall. Projects which have been using
> >> "-Wall
On 07/10/2013 10:29 AM, Jonathan Wakely wrote:
On 10 July 2013 17:11, Andi Kleen wrote:
FWIW basically -Werror -Wall defines a compiler version specific
variant of C. May be great for individual developers, but it's always
a serious mistake in any distributed Makefile.
That's a very nice way t
On Jul 10, 2013, at 12:44 PM, Jeff Law wrote:
> On 07/10/2013 10:29 AM, Jonathan Wakely wrote:
>> On 10 July 2013 17:11, Andi Kleen wrote:
>>> FWIW basically -Werror -Wall defines a compiler version specific
>>> variant of C. May be great for individual developers, but it's always
>>> a serious m
On 07/10/2013 05:48 PM, paul_kon...@dell.com wrote:
> It seems to me there are two cases. One is releases, where you want to
> maximize the odds that an install will work. For that you clearly don't want
> -Werror, and you might want to trim back the warnings. The other is the
> development p
Is there any way manually disable generation of IFUNC symbols through GCC
parameters?
I found number of in-code conditions to check if IFUNC is supported, but didn't
found the way to force them.
defaults.h hase the following code:
112 #ifndef IFUNC_ASM_TYPE
113 #define IFUNC_ASM_TYPE "gnu_indir
On Wed, Jul 10, 2013 at 10:19 AM, Evgeny Gavrin
wrote:
> Is there any way manually disable generation of IFUNC symbols through GCC
> parameters?
Why do you want to do that? Also GCC does not output directly ifunc's
at all, rather the person who write code uses ifuncs.
Thanks,
Andrew
>
> I fo
What about introducing a new blanket warning kind that excludes
anything with false positives? something like -WALL ?
David
On Wed, Jul 10, 2013 at 3:51 AM, Andreas Arnez wrote:
> Jeff Law writes:
>
>> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>>> Andrew Haley writes:
>>>
On 07/09/2013
On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote:
> What about introducing a new blanket warning kind that excludes
> anything with false positives? something like -WALL ?
I am doubtful "more ropes" is the answer.
-- Gaby
On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote:
>> What about introducing a new blanket warning kind that excludes
>> anything with false positives? something like -WALL ?
>
> I am doubtful "more ropes" is the answer.
>
Reason
On Wed, Jul 10, 2013 at 2:27 PM, Xinliang David Li wrote:
> On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis
> wrote:
>> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li
>> wrote:
>>> What about introducing a new blanket warning kind that excludes
>>> anything with false positives? somethin
There are two fundamental problems:
1) uninit warning has false positives.
2) people disagree what is the expected behavior of -Wall.
1) can only be solved by improving the analysis. The new option is a
reasonable way to solve 2), unless you think the only way to solve it
is to change the behavio
Xinliang David Li writes:
> What about introducing a new blanket warning kind that excludes
> anything with false positives? something like -WALL ?
This still doesn't help if any new compiler version
could ever add a new warning.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote:
> There are two fundamental problems:
> 1) uninit warning has false positives.
> 2) people disagree what is the expected behavior of -Wall.
>
> 1) can only be solved by improving the analysis.
I think we should focus on this. While we can
Hi, I have a hard time finding a good description of how old, obsolete
and now poisoned target macros and backend switches had been replaced
with. Examples are TARGET_SWITCHES, or CAN_DEBUG_WITHOUT_FP. I am
porting from a very old compiler version. Is there any documentation
(except ChangeLog which
On Wed, Jul 10, 2013 at 1:20 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote:
>> There are two fundamental problems:
>> 1) uninit warning has false positives.
>> 2) people disagree what is the expected behavior of -Wall.
>>
>> 1) can only be solved by improv
Hendrik Greving writes:
> Hi, I have a hard time finding a good description of how old, obsolete
> and now poisoned target macros and backend switches had been replaced
> with. Examples are TARGET_SWITCHES, or CAN_DEBUG_WITHOUT_FP. I am
> porting from a very old compiler version. Is there any doc
> This points to other ideas:
> 1) how about adding a helper switch to show what is included in Wall?
> such as -Wall-print
Doesn't
gcc -Q -Wall --help=warnings
give you this?
Otherwise, I think it is a bug.
> 2) how about making -Wall configurable -- a default config file is
> looked at by th
On Wed, Jul 10, 2013 at 2:37 PM, Manuel López-Ibáñez
wrote:
>> This points to other ideas:
>> 1) how about adding a helper switch to show what is included in Wall?
>> such as -Wall-print
>
> Doesn't
>
> gcc -Q -Wall --help=warnings
>
> give you this?
>
Yes it does work as expected.
> Otherwise,
On Wed, Jul 10, 2013 at 4:37 PM, Manuel López-Ibáñez
wrote:
> To be honest, I agree with Gabriel here. And I would go a step
> forward, I would say that we are too timid with the warnings we enable
> by default or by -Wall. We should warn more agressively, and let users
> disable the warnings tha
On Wed, 10 Jul 2013 07:49:18 -0500
Gabriel Dos Reis wrote:
> If we include a warning in -Wall then it is because we believe it to be
> generally useful and likely to uncover common bugs/mistakes. It is therefore
> reasonable for users to issue -Wall -Werror even in application delivery mode.
Ar
37 matches
Mail list logo
