Do we really want to quote to this level? This message has 11 levels of
quotes, the most I have ever seen. If everyone does this, the whole
thread is in every message and that seems unnecessary. I don't know if
there are gcc guidelines on this???
On 3/18/2015 9:59 AM, Ilya Enkovich wrote:
On 12/10/2014 11:49 AM, Richard Henderson wrote:
On 12/04/2014 01:49 AM, Ilya Tocar wrote:
+ if (!TARGET_AVX512BW || !(d-vmode == V64QImode))
Please don't over-complicate the expression.
Use x != y instead of !(x == y).
To me the original reads more clearly, since it
is of the parallel
On 8/31/2014 4:49 PM, Gerald Pfeifer wrote:
On Fri, 29 Aug 2014, Mike Stump wrote:
These errors are on purpose.
Surprising that someone would not get this obvious clever joke.
-There are many places in which this document is incomplet and incorrekt.
+There are many places in which this
There's a user's group that works with VMS engineering that wants to
keep using the C compiler, so let's keep the config files and non-Ada
specific C files. Tristan and I will stay on as maintainers of the
cross port for now.
Why should we continue to maintain these?
On 2/11/2014 4:45 AM, Richard Sandiford wrote:
OK, this version drops the [enabled by default] altogether.
Tested as before. OK to install?
Still a huge earthquake in terms of affecting test suites and
baselines of many users. is it really worth it? In the case of
GNAT we have only recently
On 2/11/2014 7:48 AM, Richard Sandiford wrote:
The patch deliberately didn't affect Ada's diagnostic routines given
your comments from the first round. Calling this a huge earthquake
for other languages seems like a gross overstatement.
Actually it's much less of an impact for Ada for two
On 2/11/2014 9:36 AM, Richard Sandiford wrote:
I find it hard to believe that
significant numbers of users are not fixing the sources of those
warnings and are instead requiring every release of GCC to produce
warnings with a particular wording.
Good enough for me, I think it is OK to make
On 2/9/2014 3:00 PM, Richard Sandiford wrote:
We print [-Wfoo] after a warning that was enabled by the -Wfoo option,
which is pretty clear. But for warnings that have no -W option we just
print [enabled by default], which leads to the question of _what_ is
enabled by default. As shown by:
On 2/9/2014 3:03 PM, Richard Sandiford wrote:
This switches Ada from using [enabled by default] to [warning enabled
by default] for consistency with:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html
Tested on x86_64-linux-gnu. OK if the above patch goes in?
I would say hold off on
On 2/9/2014 3:09 PM, Arnaud Charlet wrote:
IMO the natural assumption is that gnu++11 is enabled by default, which is
how Lars also read it.
There seemed to be support for using warning enabled by default instead,
so this patch does that. Tested on x86_64-linux-gnu. OK to install?
I'll post
On 2/9/2014 3:10 PM, Richard Sandiford wrote:
Which testsuite do you mean? I did test this with Ada enabled
and there were no regressions.
If you mean an external testsuite then I certainly don't mind
holding off the Ada part. I hope the non-Ada part could still
go in without it though.
I
On 2/9/2014 3:23 PM, Richard Sandiford wrote:
can't we just reword the one warning where there is an ambiguity to
avoid the confusion, rather than creating such an earthquake, which
as Arno says, really has zero advantages to Ada programmers, and clear
disadvantages .. to me [enabled by
On 1/7/2014 8:46 PM, Andrew Pinski wrote:
Correctness over speed is better. I am sorry GCC is the only one
which gets it correct here. If people don't like there is a flag to
disable it.
Obviously in a case like this, it is the programmer who should
be able to decide between
To me the issue is not what is written down about
the policy, but whether the policy works in practice,
and it seems like it does, so what's the problem?
This just seems to be making a problem where
none exists.
On 11/4/2013 2:23 PM, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
The removed code is too old. To be honest, I even don't remember why I
added this. LRA has been changed a lot since this change and now it
works fine without it.
On 10/3/2013 5:10 PM, Joseph S. Myers wrote:
On Wed, 2 Oct 2013, Joern Rennecke wrote:
From my understanding, the condition for adding the current Copyright year
without a source code change is to have a release in that year. Are we
sure 4.9.0 will be released this year?
release here
On 6/1/2013 9:52 AM, Jakub Jelinek wrote:
Sorry for nitpicking, but there are various formatting issues.
A number of these formatting issues could be easily detected by
the compiler. It might be really useful to add a switch to do
such detection. For Ada, the GNAT compiler has -gnatyg which
On 5/11/2013 5:42 AM, jacob navia wrote:
1) The fsin instruction is ONE instruction! The sin routine is (at
least) thousand instructions!
Even if the fsin instruction itself is slow it should be thousand
times faster than the
complicated routine gcc calls.
2) The FPU is at 64 bits
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
cat
#include math.h
int main(){ int i;
double x=0;
double ret=0;
double f;
On 5/11/2013 10:46 AM, Robert Dewar wrote:
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
And of course this experiment says nothing about accuracy!
. Certainly
you have to be a floating-point expert to even touch it!
Robert Dewar
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG expanded code listing clearly shows in
Ada
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediate value is
outside this range.
all
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
On 4/8/2013 9:24 AM, Kenneth Zadeck wrote:
So then how does a language like ada work in gcc? My assumption is
that most of what you describe here is done in the front end and by the
time you get to the middle end of the compiler, you have chosen types
for which you are comfortable to have any
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
expect the math to be done within that type,
On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
My confusion is what you mean by we? Do you mean we the writer of
the program, we the person invoking the compiler by the use command
line options or we, your company's implementation of ada?
Sorry, bad usage, The gcc implementation of Ada allows
On 4/8/2013 5:12 PM, Lawrence Crowl wrote:
(BTW, you *really* don't need to quote entire messages, I find
it rather redundant for the entire thread to be in every message,
we all have thread following mail readers!)
Correct me if I'm wrong, but the Ada standard doesn't require any
particular
On 4/8/2013 5:46 PM, Kenneth Zadeck wrote:
In some sense you have to think in terms of three worlds:
1) what you call compile-time static expressions is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar de...@adacore.com wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifically encourages
On 4/8/2013 7:46 PM, Kenneth Zadeck wrote:
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar de...@adacore.com wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision
Forgive me, but I don't see where anything is guaranteed to be zero'd
before use. I'm likely wrong somewhere since you disagree.
http://en.wikipedia.org/wiki/.bss
This is about what happens to work, and specifically notes that it is
not part of the C standard. There is a big difference
Wrong. It specifies that objects with static storage duration that
aren't explicitely initialized are initialized with null pointers, or
zeros depending on type. 6.7.8.10.
OK, that means that the comments of my last mesage don't apply to
variables of this type. So they should at least
On 1/28/2013 6:48 AM, Alec Teal wrote:
On 28/01/13 10:41, Jonathan Wakely wrote:
On 28 January 2013 06:18, Alec Teal wrote:
the very
nature of just putting the word hard before a typedef is something I find
appealing
I've already explained why that's not likely to be acceptable, because
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong
On 1/24/2013 10:02 AM, Jeffrey Walton wrote:
What I am not clear about is when an operation is deemed undefined
or implementation defined.
The compiler is free to assume that no arithmetic operation
on signed integers results in overflow. It is allowed to
take advantage of such assumptions in
On 1/24/2013 10:33 AM, Jeffrey Walton wrote:
In this case, I claim we must perform the operation. Its the result
that we can't use under some circumstances (namely, overflow or wrap).
You do not have to do the operation if the program has an
overflow. The compiler can reason about this, so
About the time Clang does because GCC now has to compete.
How about that? Clang is currently slightly ahead and GCC really needs
to change if it is to continue to be the best.
Best is measured by many metrics, and it is unrealistic to expect
any product to be best in all respects.
Anyway, it
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.
The fact that
On 1/2/2013 12:26 PM, Jeff Law wrote:
Any thoughts on doing something similar?
I've always found lazily updating the copyright years to be error prone.
If we could just update all of them now, which is OK according to the
FSF guidelines we could avoid one class of problems.
For GNAT at
On 12/15/2012 12:42 AM, Ralf Corsepius wrote:
If you want a port to be live show that it is live by posting regular
testresults to gcc-testresults.
Not all of this world is Linux nor backed by large teams at
companies :) We simply do not have the resources do to this.
But that's the
On 12/15/2012 12:32 PM, Cynthia Rempel wrote:
Hi,
Thanks for the fast response!
So to keep an architecture supported by GCC, we would need to:
Three or more times a year preferably either during OR after
stage3
1. use the SVN version of gcc, 2. patch with an RTEMS patch, 3. use
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the benefits are small,
and the impact would be serious for
Having read this whole thread, Ivote for deprecating the 386.
People using this ancient architecture can perfectly well use
older versions of gcc that have this support.
Intel stopped producing embedded 386 chips in 2007.
Right, but this architecture is not protected, so the
question is whether there are other vendors producing
compatible chips. I don't know the answer.
On 12/13/2012 7:26 AM, Steven Bosscher wrote:
Ralf has found one such a vendor, it seems.
But to me, that doesn't automatically imply that GCC must continue to
support such a target. Other criteria should also be considered. For
instance, quality of implementation and maintenance burden.
On 12/12/2012 1:01 PM, Steven Bosscher wrote:
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The oldest ix86 variant that'd be supported would be i486.
Are there any embedded chips that still use the 386 instruction set?
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy :-)
But if no sign of 386 embedded chips,
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads
:-( Surely these are just normal text
On 12/7/2012 2:09 PM, Mike Stump wrote:
On Dec 7, 2012, at 10:57 AM, Robert Dewar de...@adacore.com wrote:
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
On 12/7/2012 2:16 PM, Mike Stump wrote:
Yes, you can strip them, no problem.
Since emails likely crossed paths…. I'm going to give you and Robert a change
to figure out what you'd like to do… I _only_ care about consistency between
contents as seen from svn and git. Stripping ^M can do
On 12/7/2012 2:50 PM, Arnaud Charlet wrote:
Anyway, I'll let Robert have the final word on this one.
I'm fine with either solution (converting to LF, or marking files binary,
or a mix of both).
Arno
I would convert to LF, I think it causes less confusion
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely there are altenrative email client for Android that have plain
text capability???
On 11/24/2012 12:59 PM, Daniel Berlin wrote:
On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar de...@adacore.com wrote:
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely
On 11/24/2012 1:13 PM, Jonathan Wakely wrote:
The official gmail app, which obviously integrates well with gmail and
is good in most other ways, won't send non-html mails.
There seem to be a variety of alternatives
For me the most annoying thing about HTML burdened emails
is idiots who choose totally inappropriate fonts, that make
their stuff really hard to read. I choose a font for plain
text emails that is just right on my screen etc. I do NOT
want it overridden. And as for people who use color etc,
well
confirm your
intepretation, but it's risky to rely on such opinions.
BTW, it is no surprise that you got no response from
licens...@fsf.org.
Robert Dewar
I'm pretty certain I have correctly interpreted GPL,v3. I have good
reasons to believe that. However, I'm willing to read your
interpretation of the GPL,v3, if you have any.
If you are certain enough, then you can of course proceed
on that assumption. I have no interest in giving my opinion
on
On 11/7/2012 8:17 AM, nk...@physics.auth.gr wrote:
I disagree.
I think you are wrong, however it is not really productive to express it.
I would not casually ignore Richard's opinion, he has FAR more
experience here than you do, and far more familiarity with
the issues involved.
On 11/7/2012 9:44 AM, nk...@physics.auth.gr wrote:
Quoting Richard Kenner ken...@vlsi1.ultra.nyu.edu:
There are not many lawyers in Greece that deal with open-source licenses.
The legal issue here has nothing whatsoever to do with open-source
licenses: the exact same issue comes up with
On 11/7/2012 11:08 AM, Richard Kenner wrote:
Correct. A court of competent jurisdiction can decide whether your scheme
conforms to the relevant licenses; neither licens...@fsf.org nor the
people on this list can.
A minor correction: licens...@fsf.org *could* determine that since they are
the
On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
On Wed, 10 Oct 2012, Gabor Loki wrote:
2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra -E option to preprocess every sources.
On 10/10/2012 4:16 PM, Joseph S. Myers wrote:
I'm not talking about the relation between the headings textually located
in a source file and the license of that source file. I'm talking about
the relation between the license of a .o file and the license of .h files
#included at several levels
On 10/8/2012 11:01 AM, Nathan Froyd wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks
On 10/1/2012 6:09 PM, Steven Bosscher wrote:
I suppose no-one would object if I commit this as obvious at some point?
Index: lra-constraints.c
===
--- lra-constraints.c (revision 191858)
+++ lra-constraints.c (working copy)
@@
On 9/26/2012 4:19 PM, Tom Tromey wrote:
Florian == Florian Weimer fwei...@redhat.com writes:
Florian This patch adds support for #pragma GCC warning and #pragma GCC
Florian error. These pragmas can be used from preprocessor macros,
Florian unlike the existing #warning and #error directives.
On 9/24/2012 6:53 AM, Jerome Huck wrote:
from Mr Jerome Huck
Good morning.
I have been using the GCC suite on Windows, mainly in the various
Fortran. 77, 2003,... Thanks for those tools ! The Little Google Nexus 7
seems a wonderfull tool. I would like to know if we can expect a version
of GCC
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted. In practice, gdb for me is so weak in handling
-O1 or -O2, that if I want to debug
On 9/13/2012 9:38 AM, Jakub Jelinek wrote:
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
, see
my follow on message.
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar de...@adacore.com wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
On 9/13/2012 12:46 PM, Tom Tromey wrote:
Robert == Robert Dewar de...@adacore.com writes:
Robert Sometimes I wonder whether the insistence on -g not changing code
Robert generation is warranted. In practice, gdb for me is so weak in handling
Robert -O1 or -O2, that if I want to debug something
On 7/2/2012 8:35 AM, Alexandre Oliva wrote:
On Jun 30, 2012, David Edelsohn dje@gmail.com wrote:
IBM's policy specifies a comma:
first year, last year
and not a dash range.
But this notation already means something else in our source tree.
I think using the dash is preferable,
On 7/2/2012 8:35 AM, Alexandre Oliva wrote:
On Jun 30, 2012, David Edelsohn dje@gmail.com wrote:
IBM's policy specifies a comma:
first year, last year
and not a dash range.
But this notation already means something else in our source tree.
I think using the dash is preferable,
On 6/24/2012 11:22 AM, Richard Guenther wrote:
I suppose I think it would be reasonable to issue a -Wall warning for
code like that. The trick is detecting it. Obviously there is nothing
wrong with a recursive call. What is different here is that the
recursive call is unconditional. I don't
On 6/24/2012 12:09 PM, Ángel González wrote:
Peter A. Felvegi writes:
My question is: wouldn't it be possible to print a warning when a jmp
to itself or trivial infinite recursion is generated? The code
compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7.
Note that if the target architecture
On 5/18/2012 4:27 PM, Ulrich Weigand wrote:
I finally got some time to look into this in detail. The various special-
case transforms in associate_plusminus all transform a plus/minus expression
tree into either a single operand, a negated operand, or a single plus or
minus of two operands.
On 5/14/2012 11:22 PM, Hans-Peter Nilsson wrote:
Random non-maintainer comments: I'd suggest adding a nearby
comment to avoid a future edit changing it back. The attachment
with the patch had the mime-type Video/X-DV, maybe indicating
an issue with your mail-client setup mismatching the .dif
On 5/14/2012 6:26 PM, Andy Lutomirski wrote:
This seems to defeat the purpose, and adding
#pragma GCC diagnostic ignored -Wpragmas
is a little gross. How am I supposed to do this?
The gcc mailing list is for gcc development, not
quetions about the use of gcc, please address such
questions to
On 4/30/2012 4:16 AM, Paulo J. Matos wrote:
Peter,
We have a working backend for an Harvard Architecture chip where
function pointer and data pointers have necessarily different sizes. We
couldn't do this without changing GCC itself in strategic places and
adding some extra support in our
On 4/29/2012 8:51 AM, Georg-Johann Lay wrote:
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If
On 4/29/2012 9:25 AM, Andreas Schwab wrote:
Robert Dewarde...@adacore.com writes:
Just to be clear, there is nothing in the standard that forbids the
sizes being different AFAIK? I understand that both gcc and apps
may make unwarranted assumptions.
POSIX makes that assumption, via the dlsym
On 4/29/2012 12:47 PM, Basile Starynkevitch wrote:
My biased point of view is that designing a processor instruction set (for
POSIX-like
systems or standard C software in mind) with function pointers of different
size than
data pointers is today a mistake: most software make the implicit
On 4/29/2012 1:19 PM, Basile Starynkevitch wrote:
For instance, I don't think that porting the Linux kernel (or the FreeBSD one)
to such an
architecture (having data pointers of different size that function pointers) is
easy.
Well it doesnt' surprise me too much that GNU/Linux has
On 4/16/2012 5:36 AM, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewarde...@adacore.com wrote:
hand, but to suggest banning all templates is not a supportable
notion.
Why ?
Because some simple uses of templates are very useful, and
not problematic from any point of view.
On 4/13/2012 9:15 PM, Chiheng Xu wrote:
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...
Probably, if you can refrain from using some advance C++
On 4/14/2012 6:38 AM, Chiheng Xu wrote:
Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the
On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:
Indeed, the notion that 'namspace' is advance is troublesome.
Similarly I would find any notion that simple uses and definitions
of templates (functions, datatypes) advanced a bit specious.
Indeed! In the case of templates there is a real issue,
On 4/14/2012 6:02 AM, Chiheng Xu wrote:
If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.
But personally, when I write C++ code, I never use namespace. I
always prefix my class name(and corresponding source file
On 4/13/2012 2:03 AM, Gabriel Dos Reis wrote:
On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewarde...@adacore.com wrote:
End of thread for me, remove me from the reply lists, thanks
discussion is going nowhere, at this stage my vote is for
no change whatever in the way warnings are handled.
I was
On 4/12/2012 4:55 AM, Fabien Chêne wrote:
I've got a radically different experience here, real bugs were
introduced while trying to remove this warning, and as far as I can
tell, I've never found any bugs involving precedence of and || --
in the code I'm working on --, whose precedence is
On 4/12/2012 5:55 AM, Miles Bader wrote:
... and it's quite possible that such bugs resulting from adding
parentheses means that the programmer fixing the code didn't
actually know the right precedence!
or that the layout (which is what in practice we should rely on
to make things clear with
On 4/12/2012 6:44 AM, Andrew Haley wrote:
I would also suggest that a competent programmer would know what they
don't know; when reading code they'd look it up, when writing code
they'd insert parentheses for clarity.
Yes, of course I 100% agree with that. But then by your definition
code
On 4/12/2012 9:30 AM, Andrew Haley wrote:
Sorry for the confusion: I intended to write
I would also suggest that your competent programmer would know what
they don't know; when reading code they'd look it up, when writing
code they'd insert parentheses for clarity.
Using two different
On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
-W0: no warnings (equivalent to -w)
-W1: default
-W2: equivalent to the current -Wall
-W3: equivalent to the current -Wall -Wextra
I like this suggestion a lot.
Me too!
I also like short switches, but gcc mostly favors long
hard-to-type
On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote:
What is nonsensical there?
But they *are* ordinal.
Now? What is the order?
less warnings to more warnings, what could be more
ordered than that!
It works just fine for -O,
Exactly what happens with -O? -On does not necessarily
On 4/12/2012 10:48 AM, Andrew Haley wrote:
Certainly, everything that adds to clarity (and has no runtime costs!)
is desirable. But adding parentheses may not add to clarity if doing
so also obfuscates the code. There is a cost to the reader due to a
blizzard of syntactically redundant
On 4/12/2012 11:23 AM, Gabriel Dos Reis wrote:
less warnings to more warnings, what could be more
ordered than that!
What exactly do you put in -Wn to make it give *more* warning?
I can think of a reduced number of switch that would give you
more warning on a specific program without them
1 - 100 of 990 matches
Mail list logo
