--- Comment #17 from manu at gcc dot gnu dot org 2006-11-23 18:39 ---
Subject: Bug 9072
Author: manu
Date: Thu Nov 23 18:39:32 2006
New Revision: 119129
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119129
Log:
2006-11-23 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #7 from manu at gcc dot gnu dot org 2006-11-24 01:50 ---
Subject: Bug 2707
Author: manu
Date: Fri Nov 24 01:50:33 2006
New Revision: 119143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119143
Log:
2006-11-24 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c/2707
--- Comment #15 from manu at gcc dot gnu dot org 2006-11-24 01:50 ---
Subject: Bug 26167
Author: manu
Date: Fri Nov 24 01:50:33 2006
New Revision: 119143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119143
Log:
2006-11-24 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #16 from manu at gcc dot gnu dot org 2006-11-24 01:56 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from manu at gcc dot gnu dot org 2006-11-24 01:59 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #11 from manu at gcc dot gnu dot org 2006-11-25 13:51 ---
I don't get the warning with current mainline (revision 119143).
Still, I would like to keep this bug around since it may be interesting that
Wconversion emits a warning for the int-char conversion. I would like
--- Comment #2 from manu at gcc dot gnu dot org 2006-11-25 14:06 ---
As far as I can see, the C++ front-end fails to call overflow_warning
(c-common.c) from build_binary_op (cp/typeck.c) in the same way as the C
front-end does in parser_build_binary_op(c-typeck.c).
--
manu at gcc
--- Comment #5 from manu at gcc dot gnu dot org 2006-11-25 15:24 ---
Why this is marked as other ? This is either a problem on the C/C++
front-ends or it is a problem in the middle-end that doesn't handle the
overflow/underflow correctly during conversion, isn't it?
Also, this happens
--- Comment #1 from manu at gcc dot gnu dot org 2006-11-26 13:38 ---
Hi, Richard.
I don't understand completely what you mean. Is the problem in the builtin
exp() ? Should it check its argument for large numbers?
--
manu at gcc dot gnu dot org changed:
What
--- Comment #4 from manu at gcc dot gnu dot org 2006-11-26 13:57 ---
This will be fixed by the new Wconversion option. Actually, it has been fixed
already for gcc version 4.3.0 20061124 (experimental).
[EMAIL PROTECTED]:~$ local/bin/g++ -c -Wconversion pr18821.C
pr18821.C: In function
--- Comment #5 from manu at gcc dot gnu dot org 2006-11-26 13:59 ---
For reference:
Author: manu
Date: Fri Nov 24 01:50:33 2006
New Revision: 119143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119143
Log:
2006-11-24 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c/2707
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18821
--- Comment #4 from manu at gcc dot gnu dot org 2006-11-26 19:27 ---
(In reply to comment #3)
(In reply to comment #2)
The problem is that we reset TREE_OVERFLOW:
It would seem it overflows incremented, and underflow's decremented,
only a terminal non-zero count would represent
--- Comment #3 from manu at gcc dot gnu dot org 2006-11-28 22:35 ---
Roger,
The patch below fixes this bug. But it also introduces bug 19978 (multiple
warnings) in the C++ front-end. Yet, all regression testcases pass. They pass
because C++ overflow testcases are very limited
--- Comment #6 from manu at gcc dot gnu dot org 2006-12-01 00:31 ---
(In reply to comment #5)
(In reply to comment #2)
Subject: Re: Gcc doesn't check overflowed size of structure
If you rewrite it to
That is because there is no constant overflow. Just an overflow
--- Comment #2 from manu at gcc dot gnu dot org 2006-12-01 02:37 ---
Hi Roger,
I am not sure how we are going to handle this.
First, the 1/0 is detected at int_const_binop at line 1509
--
case ROUND_DIV_EXPR:
if (int2h == 0 int2l == 0
--- Comment #4 from manu at gcc dot gnu dot org 2006-12-01 23:36 ---
I am working in a patch but don't expect it too soon. Yet, I am quite advanced,
that is why I am accepting it. If this is not the proper way to do it, please
let me know.
--
manu at gcc dot gnu dot org changed
--- Comment #6 from manu at gcc dot gnu dot org 2006-12-03 21:02 ---
(In reply to comment #3)
Hi Manual,
Manuel (or Manu) http://en.wikipedia.org/wiki/Manuel
not manual: http://en.wikipedia.org/wiki/Manual
:-)
The real issue is that OPT_Wdiv_by_zero needs to be enabled
--- Comment #3 from manu at gcc dot gnu dot org 2006-12-03 21:12 ---
(In reply to comment #2)
The problem is that we believe we can handle all errno checking/setting via
the expand_errno_check() routine which is not true for overflow/underflow but
only for invalid arguments
--- Comment #2 from manu at gcc dot gnu dot org 2006-12-09 14:28 ---
I believe that the culprit is a call to constant_expression_warning at
c-typeck.c (store_init_value). The comment just above this call says ANSI
wants warnings about out-of-range constant initializers. However
--- Comment #5 from manu at gcc dot gnu dot org 2006-12-09 21:51 ---
Why is this accepts-invalid? Shouldn't it be diagnostic instead? I am
trying to understand what is the expected output here: a warning or a pedantic
error?
--
manu at gcc dot gnu dot org changed:
What
--- Comment #2 from manu at gcc dot gnu dot org 2006-12-11 19:35 ---
(In reply to comment #1)
I think the C front-end is incorrect in not warning, though someone has to
look
into the standard to be sure.
Is there a searchable version of the standard?
Anyway, the following code
--- Comment #8 from manu at gcc dot gnu dot org 2006-12-11 20:52 ---
(In reply to comment #5)
int x;
enum e { E = 0 * x };
which currently compiles without even a warning using -pedantic-errors.
This is exactly the sort of thing that Joseph's struct c_expr were intended
--- Comment #7 from manu at gcc dot gnu dot org 2006-12-16 16:48 ---
Subject: Bug 7651
Author: manu
Date: Sat Dec 16 16:48:01 2006
New Revision: 119963
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119963
Log:
2006-12-16 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR middle
--- Comment #10 from manu at gcc dot gnu dot org 2006-12-22 15:54 ---
Subject: Bug 7651
Author: manu
Date: Fri Dec 22 15:54:05 2006
New Revision: 120151
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120151
Log:
2006-12-22 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #11 from manu at gcc dot gnu dot org 2006-12-23 17:45 ---
Subject: Bug 7651
Author: manu
Date: Sat Dec 23 17:45:33 2006
New Revision: 120173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120173
Log:
2006-12-23 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #16 from manu at gcc dot gnu dot org 2007-01-02 17:33 ---
Subject: Bug 7651
Author: manu
Date: Tue Jan 2 17:33:25 2007
New Revision: 120347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120347
Log:
2007-01-02 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-02 20:07 ---
Subject: Bug 19977
Author: manu
Date: Tue Jan 2 20:07:44 2007
New Revision: 120355
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120355
Log:
2007-01-02 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-05 21:57 ---
Subject: Bug 19978
Author: manu
Date: Fri Jan 5 21:57:01 2007
New Revision: 120505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120505
Log:
2007-01-05 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-06 09:34 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-06 09:36 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-07 23:40 ---
Subject: Bug 28986
Author: manu
Date: Sun Jan 7 23:39:55 2007
New Revision: 120558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120558
Log:
2007-01-07 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-09 14:19 ---
What name do you want for the warning? Wenum-mismatch ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 14:24 ---
I could also add it to the new -Wconversion option. I think it is appropriate.
Yet that would change default behaviour, since this warning is unconditional
and -Wconversion must be explicitly enabled
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-09 14:36 ---
This seems similar to PR 12963. I am preparing a patch for this
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-09 14:43 ---
I think you should bring the issue in the GCC mailing list to check out what
people think. Also, if you could propose a name and testcases (for warning and
for not warning), it would help whoever takes the burden
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-09 14:50 ---
There is an unreviewed patch to name this warning in the patch queue:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00520.html
I guess it doesn't solve all the inconsistencies mentioned here but at least it
can
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 14:57 ---
Another Wsequence-point bug is PR 17880.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:02 ---
Have you tried compiling with -pedantic -Wall -Wextra ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21917
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:06 ---
Is the warning a good idea because it is a function call, so it may be a
confused call to quak, or simply because it is unsigned converted to enum ?
--
manu at gcc dot gnu dot org changed:
What
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 15:09 ---
(In reply to comment #0)
Is this a bug either in GCC or a bug in documentation?
It is a bug in the documentation. As today in GCC 4.3 there is not a single
Wextra warning that has anything to do with floating
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-09 15:15 ---
Maybe we shouldn't show any warning when converting NULL to boolean. Perhaps in
time for the new Wconversion option...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-09 15:21 ---
Wextra warns for this, what is the bug?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-09 15:30 ---
(convert_like_real gives me the creeps.)
I must check whether this warning has been taken by the new Wconversion, which
is not currently enabled by Wall.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-09 16:03 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-09 20:28 ---
(In reply to comment #4)
Subject: Re: missed warnings about comparisons which are always true/false.
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Wextra warns for this, what is the bug?
I believe
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-11 16:00 ---
This seems like a regression to me.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-13 02:23 ---
There is no warning with GCC 4.3 and you can get a warning for the int-char
conversion by using -Wconversion. So I am going to close this. Please, feel
free to reopen if you think there is some unresolved issue
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 11:13 ---
Why Wall is not in common.opt ? As far as I know, that would be the right fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-14 23:03 ---
Gerald,
One thing is whether the warning was incorrect or not. Looking at the code and
the definition of Wconversion, what do you think?
Another thing is whether we want or not to emit warnings for libstdc++. I don't
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-14 23:15 ---
So I cannot understand why are we warning. Warnings in system headers should
only be emitted when using -Wsystem-headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 23:37 ---
Sorry I read your reply later.
So, that is it, isn't it? Wsystem-headers needs to be fixed since we don't want
to emit warnings for system headers even if those warnings are correct.
--
http://gcc.gnu.org
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-15 08:55 ---
Thanks for your patch but if you want it to be reviewed, it is better to send
it to [EMAIL PROTECTED] .
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-16 22:02 ---
(In reply to comment #5)
Created an attachment (id=7299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit]
proposed patch
I've attached a more official-looking patch, with a testsuite
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-16 22:35 ---
(In reply to comment #5)
Created an attachment (id=7299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit]
proposed patch
I've attached a more official-looking patch, with a testsuite
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-17 00:47 ---
#include cassert
template typename Int, Int D
void f(Int x) {
assert(0 = x and x = D);
}
int main() {
funsigned char, 2(5);
fsigned char, 2(5);
}
We don't emit a warning when instantiated as a signed char, so
--- Comment #15 from manu at gcc dot gnu dot org 2007-01-17 01:11 ---
(In reply to comment #14)
| We don't emit a warning when instantiated as a signed char, so everything
boils
| down to having an option to disable the warning, doesn't it?
the logical inference escapes me
--- Comment #19 from manu at gcc dot gnu dot org 2007-01-17 03:49 ---
(In reply to comment #16)
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #14)
| | We don't emit a warning when instantiated
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-17 13:47 ---
Perhaps Wundefined should warn for PR 29465 ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-17 13:49 ---
Also, not sure whether Wundefined or Wsequence-points should handle PR 24016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-17 13:52 ---
Another candidate is PR 30457.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-17 14:00 ---
Not so sure about this one PR 12411
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-17 14:04 ---
Not sure about this one either, there seems to be a warning in C++ but I am not
sure what option controls it now: PR 30368.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-17 19:12 ---
I am also new, my first patch was just a few months ago, so let me say that I
understand your situation. On the other hand, I got patches committed, so also
let me say that it is not as bad as you may think
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-19 16:05 ---
Subject: Bug 17947
Author: manu
Date: Fri Jan 19 16:04:57 2007
New Revision: 120969
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120969
Log:
2007-01-19 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-19 16:10 ---
Fixed for GCC 4.3.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 10:15 ---
Paolo or Gerald, could you try to collect a list of the warnings produced by
-Wconversion? I am only interested in the warning message, not where it was
instantiated, so please, filter it through fgrep warning: .
You
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-20 12:32 ---
I am also interested in seeing if there are any (large signed) - (small
unsigned) and bring them to the discussion, where all positive values fit in
the unsigned (so no warning) or there is a sign conversion.
About
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-20 12:43 ---
Note: we emit a duplicated warning because this patch is not committed yet:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html
(Not a single comment yet).
With the patch the output is just:
int g() T h() int
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:30 ---
This is a duplicate of PR 23587.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29694
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:52 ---
Not sure if the summary is 100% correct but it is far better than the previous
one.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 18:06 ---
Any news on this? Is this an important warning?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-21 17:24 ---
There is some initial support for this:
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9049
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-21 17:47 ---
I was thinking about adding this to Wconversion. But perhaps it is more
appropriate for Wundefined. After all, the value may change or not depending on
the particular implementation, since it is undefined.
Gabriel
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-21 18:08 ---
I am not sure this is such a good idea. A casting typically means I want to
really do this. GCC normally suppress warnings when casting is added. A
warning when you assign when enum type to another and the first enum
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-21 18:24 ---
So, do we want to fix those testcases or do we want to keep ignoring empty
enums?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-21 23:35 ---
Gabriel, what do you think about this? Does it need testcases? Should I submit
it?
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 121027
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-22 08:28 ---
(In reply to comment #5)
(In reply to comment #1)
1000 is a signed integer constant, so b*1000 is a signed integer too. I
guess the warning is ok, then.
That is only true for unsigned multiplication and signed
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-22 08:52 ---
In my opinion the patch is too old, now we have other mechanism for handling
options, and it lacks documentation updates and testcases. Also, it is a
standards conformance warning, so perhaps it should be just moved
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-22 08:58 ---
Is this really a bug in GCC? Eclipse should run GCC with a locale it can
understand. Then, if it wants to support other languages, it has to support
them also in the parser.
Or we go for the XML output? That would
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
PR 23572 has a better description of the problem and the current status.
*** This bug has been marked as a duplicate of 23572 ***
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
*** Bug 20764 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 18:11 ---
(In reply to comment #1)
So you have -Wextra -Wno-unused-parameter -Wall so the -Wno-unused-parameter
does not have an effect as it is not turned on by -Wextra but instead by
-Wall.
Humm, I disagree. -Wextra
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 23:47 ---
Does it happen with any other option apart from
-Wimplicit-function-declaration?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01 ---
The testcase given is not valid any more. Could you think in any other
testcase?
In stmt.c (expand_asm_operands) there is:
warning (0, use of memory input without lvalue in
asm
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:03 ---
If this is confirmed as a bug, why don't you submit the patch to gcc-patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 00:10 ---
Open a new bug report, please. I am going to submit a patch to fix this one and
reviewers don't like patches that do many things and the same time.
Add me to the CC list of the new report and I will look
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 00:20 ---
Hey, don't look at me. I am not sure what that means, I was just looking for
something deprecated in C front-end to make a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 13:57 ---
I don't get this. The enum value can be any integer apart from foo and bar.
Moreover, since it is undefined, it can be literally anything! So you need a
default: case to handle that.
In the first testcase, without
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 14:13 ---
Could you provide a smaller testcase?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 14:28 ---
What about a warning about __builtin_stdarg_start being deprecated? That will
be clearer than the current warning, and we can still keep backwards
compatibility (the user may use -Wno-deprecated to work-around
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 14:35 ---
We already have a warning about discarding qualifiers somewhere. Perhaps we
could just add this to that one (saving us from yet another warning option).
--
manu at gcc dot gnu dot org changed:
What
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-23 15:55 ---
(In reply to comment #6)
an assignment of int to enum produces an error,
so how ( in defined non-hax0r way ) enum can be any integer?
if it can be, then what's difference between enum and int?
Undefined behaviour
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 15:57 ---
(In reply to comment #7)
* PR 12242
* PR 27975
* PR 12242
This should have been:
* PR 12242
* PR 27975
* PR 30357
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-24 01:15 ---
I agree with most of what you say but, unfortunately, unless someone that can
approve a patch for this also agrees, it is pointless even to think about how
to implement it. Also, bugzilla is not closely followed by GCC
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-24 01:31 ---
(In reply to comment #4)
I think we want to fix the test cases, but I don't want to sign up to fix them
myself.
I think is not enough. It would be nice to be able tell to whoever takes the
burden of implementing
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-25 21:15 ---
Subject: Bug 30437
Author: manu
Date: Thu Jan 25 21:15:34 2007
New Revision: 121186
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121186
Log:
2007-01-25 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-26 00:22 ---
Fixed in 4.3.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-26 02:08 ---
Do we really want this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20631
1 - 100 of 1559 matches
Mail list logo
