--- Comment #5 from manu at gcc dot gnu dot org 2008-08-09 13:09 ---
Fixed in the C front-end, broken in the C++ front-end. I also have a patch for
this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-09 17:30 ---
I don't have AVR so I cannot know what exactly is going on or test a fix.
However, I guess that the limits.h used by AVR do not use #include_next. So you
could try by adding #include_next in pr36901-system.h
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-09 20:38 ---
Yeah, silly me, it obviously fails because there is no next pr36901.h to
include.
Since we include limits.h, we are at the mercy of the contents of the limits.h
that is found. This isn't very reliable. We just need
--- Comment #7 from manu at gcc dot gnu dot org 2008-08-09 23:24 ---
Testing the following patch. Not as good as ICC's diagnostic but close.
Index: gcc/testsuite/g++.dg/parse/pr20118.C
===
--- gcc/testsuite/g++.dg/parse
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-08 23:16 ---
Subject: Bug 28875
Author: manu
Date: Fri Aug 8 23:15:31 2008
New Revision: 138890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138890
Log:
2008-08-08 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 28875
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-08 23:20 ---
FIXED in GCC 4.4
Thanks for the report Behdad!
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from manu at gcc dot gnu dot org 2008-08-08 23:33 ---
Subject: Bug 7651
Author: manu
Date: Fri Aug 8 23:32:23 2008
New Revision: 138892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138892
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 7651
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-08 23:58 ---
Subject: Bug 36901
Author: manu
Date: Fri Aug 8 23:57:19 2008
New Revision: 138893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138893
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 36901
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-08 23:59 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #18 from manu at gcc dot gnu dot org 2008-08-09 00:32 ---
Subject: Bug 12242
Author: manu
Date: Sat Aug 9 00:30:41 2008
New Revision: 138898
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138898
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-09 00:35 ---
FIXED in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #16 from manu at gcc dot gnu dot org 2008-08-07 07:50 ---
The expression cannot be very complicated because it needs to be a INTEGER_CST.
On the other hand, I agree that it is best to give users as much information as
reasonable. I think it is better if you comment in gcc
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-07 11:22 ---
Then this is confirmed and it works in GCC 4.4.0
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-07 11:54 ---
Confirmed as enhancement.
To clarify how to implement this, I have some questions:
(In reply to comment #0)
-Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
defined in system headers
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-07 13:11 ---
4 years old, no activity, unconfirmed. Please fill bugs for specific targets
with testcases so the target maintainers are aware of this issue.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-07 15:22 ---
Unsubscribing: not sure what is to fix here.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2008-08-06 16:19 ---
Subject: Bug 8715
Author: manu
Date: Wed Aug 6 16:17:41 2008
New Revision: 138814
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138814
Log:
2008-08-06 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 8715
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-06 16:33 ---
Fixed in GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-06 16:38 ---
Subject: Bug 26785
Author: manu
Date: Wed Aug 6 16:37:06 2008
New Revision: 138816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138816
Log:
2008-08-06 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 26785
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-06 16:42 ---
Fixed in GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from manu at gcc dot gnu dot org 2008-08-06 18:36 ---
This is FIXED in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-06 18:42 ---
This always produces a warning by default now. Thus FIXED.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-06 20:14 ---
Reconfirmed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-06 22:26 ---
CC Jakub,
Is this initialization allowed in OpenMP or not? I have a patch that handles
it, so we can either allow it or we can give an error such:
error: parenthesized initialization not allowed in OpenMP
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-07 02:55 ---
(In reply to comment #2)
I'm not sure we should do anything about this.
We have a warning if the compiler can detect non-positive value at compile
time,
but we certainly can't ever issue any diagnostic at runtime
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-05 23:38 ---
Simon, is this fixed? If so, you should close it as FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36999
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-05 23:50 ---
Old, no version, no activity, Eclipse bug closed as WONTFIX, so we do the same.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-04 19:21 ---
In GCC 4.4 we have:
pr16663.C:2: error: variable or field Foo declared void
pr16663.C:2: error: misspelled was not declared in this scope
pr16663.C:2: error: expected primary-expression before char
pr16663.C:2
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-04 19:22 ---
Created an attachment (id=16015)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16015action=view)
testcase
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16663
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 15:28 ---
AFAIK, the error is a request of the c++0x standard and it seems -0.02435L does
not fit exactly in a float while -0.25L does, so the message is correct and I
thus I don't think there is a bug here.
Perhaps it should
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-02 19:02 ---
OK. Invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 19:03 ---
INVALID (not FIXED).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-02 19:03 ---
Wrong bug (argh!).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-02 19:04 ---
Reopened...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-02 19:05 ---
... to close as INVALID.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-01 10:08 ---
Could you provide a testcase that does not need -std=c++0x ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35852
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-01 17:54 ---
To be honest, I am not sure what deserves a warning and what not in this
testcase.
FOO is 19, ~FOO is -20. Therefore
ushort x = ~FOO seems to deserve a warning (with -Wsing-conversion at least).
x = x -20
: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37004
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-01 19:36 ---
I created PR 37004 to cover the issue with C++ front-end. Apart from that, this
bug is FIXED in GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2008-07-30 08:31 ---
Subject: Bug 34389
Author: manu
Date: Wed Jul 30 08:30:32 2008
New Revision: 138296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138296
Log:
2008-07-30 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #12 from manu at gcc dot gnu dot org 2008-07-30 08:36 ---
This should be mostly fixed except the following testcase in C++:
short mask1(short x)
{
short y = 0x7fff;
return x y; /* { dg-bogus conversion conversion { xfail *-*-* } 8 } */
}
This works in C, so it seems
--- Comment #15 from manu at gcc dot gnu dot org 2008-07-30 09:15 ---
Fix depends, add keyword, add alias Wundefined.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from manu at gcc dot gnu dot org 2008-07-30 09:26 ---
I think -Wundefined should warn for any potential undefined and unspecified
behaviour. I know they are not the same according to the standard but for a
practical point of view they both result in a behaviour
--- Comment #4 from manu at gcc dot gnu dot org 2008-07-29 10:08 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-29 10:01 ---
Subject: Bug 34985
Author: manu
Date: Tue Jul 29 10:00:25 2008
New Revision: 138235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138235
Log:
2008-07-29 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 34985
--- Comment #30 from manu at gcc dot gnu dot org 2008-07-29 13:57 ---
Dear Daniel, we would like to fix all bugs but we cannot force volunteers to
fix specific bugs and, on the other hand, hired developers fix those bugs that
are most interesting for their employers.
If this were
--- Comment #2 from manu at gcc dot gnu dot org 2008-07-29 15:43 ---
Not useful information in the bug report. Closing as invalid.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-25 14:34 ---
What Andrew means by example is a short, self-contained, compilable testcase
that shows the undesired behaviour.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-23 15:58 ---
Subject: Bug 35058
Author: manu
Date: Wed Jul 23 15:57:49 2008
New Revision: 138089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138089
Log:
2008-07-23 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 35058
--- Comment #4 from manu at gcc dot gnu dot org 2008-07-23 16:00 ---
This should be fixed in GCC 4.4. If you find any new cases please REOPEN this
with a testcase.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2008-07-22 07:20 ---
Closing as invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2008-07-22 09:46 ---
Subject: Bug 28079
Author: manu
Date: Tue Jul 22 09:45:58 2008
New Revision: 138049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138049
Log:
2008-07-22 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 28079
--- Comment #7 from manu at gcc dot gnu dot org 2008-07-22 09:48 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 09:50 ---
Better summary to find duplicates.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-07-22 09:56 ---
No reply for a long time. Old version of GCC. Closing as INVALID.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from manu at gcc dot gnu dot org 2008-07-22 09:59 ---
Not working on this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36901
--- Comment #1 from manu at gcc dot gnu dot org 2008-07-22 16:30 ---
One testcase could use #include_next in a system header and compile with just
-pedantic-errors. This should be silent but it currently emits an error.
Another testcase could be just:
static int sc = INT_MAX + 1
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 18:07 ---
(In reply to comment #2)
Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
suggestions for a fix.
I think there is a problem with my suggestion: -pedantic-errors does not only
affect
--- Comment #5 from manu at gcc dot gnu dot org 2008-07-21 14:30 ---
*** Bug 36866 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 2008-07-21 14:30 ---
To fix this testcase we would need to fix a few of the -Wuninitialized issues,
since -Wuninitialized does not work without optimisation, we don't handle VOPs
(no -Wunitialized for pointers then), and -Winit-self
--- Comment #2 from manu at gcc dot gnu dot org 2008-07-21 16:16 ---
We need a complete testcase. I tried to reproduce this but GCC 4.4 with -Wall
-Wextra -Wunused always says:
src/pr36708.c:5: warning: left-hand operand of comma expression has no effect
src/pr36708.c:5: warning
--- Comment #20 from manu at gcc dot gnu dot org 2008-07-21 16:32 ---
(In reply to comment #19)
Okay, so the two patches are now committed to trunk in changesets
r137716 and r137721.
However, given the nature of this enhancement request, I think it will take
some on going work
--- Comment #3 from manu at gcc dot gnu dot org 2008-06-08 15:36 ---
Confirmed.
The relevant gimple dump is:
int main(int, const char* const*) (D.2050, D.2051)
{
struct stringD.2032[0] * retval.0D.2067;
struct stringD.2032[0] * D.2055;
struct stringD.2032[0] * D.2056;
long
--- Comment #4 from manu at gcc dot gnu dot org 2008-06-08 15:37 ---
Not target/host specific.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
GCC build
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 16:45 ---
Confirmed.
Notes:
foo.x = bar != 0; // only warns in C, not in C++.
foo.x = bar != 0 ? 1 : 0; // warning is not a problem of bitfields but for
every conditional expression, the following also warns
short x = (bar
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 16:50 ---
In C++ we have:
ne_expr 0x2b627f00
type boolean_type 0x2b4fb9c0 bool public unsigned QI
size integer_cst 0x2b4e87b0 constant invariant 8
unit size integer_cst 0x2b4e87e0 constant
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 17:25 ---
Ideally, one could just do:
msp-small = (unsigned int:1) sm;
Meanwhile, we will need to check that when converting to p bits that the mask
is less than 2^p - 1. I wonder if we already have a function to do
--- Comment #10 from manu at gcc dot gnu dot org 2008-06-08 17:30 ---
(In reply to comment #9)
Does the patch also fix the warning for conditional expressions? For example:
short f(int cond, short x, short y)
{
return cond ? x : y;
}
No, that is a completely different issue
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 17:32 ---
Anyway, this won't work at all until bug 34389 is fixed because fold with
convert each operand to the target type before considering the bit_and_expr.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #9 from manu at gcc dot gnu dot org 2008-05-08 10:44 ---
(In reply to comment #8)
Sorry, you got it totally wrong! When someone suggests a feature that he
thinks
would be useful, he does definitely not imply that the current developers are
bored and have nothing to do
--- Comment #7 from manu at gcc dot gnu dot org 2008-05-07 10:06 ---
(In reply to comment #6)
Colorization of a message is part of the message. It should obviously be done
whereever the message is constructed. (IDE has nothing to do with this.) With
your argument, the compiler should
--- Comment #7 from manu at gcc dot gnu dot org 2008-05-07 10:12 ---
This would be more consistent if uninitialized warnings would work in VOPs.
Anyway, I think we should keep this open as an interesting testcase.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from manu at gcc dot gnu dot org 2008-04-27 22:13 ---
*** Bug 36050 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-04-27 22:13 ---
*** This bug has been marked as a duplicate of 25733 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from manu at gcc dot gnu dot org 2008-04-21 13:07 ---
Reopened per new testcase.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-04-18 15:08 ---
The C/C++ front-end plays games for bitwise operators, so it may drop the casts
but then use the original type or surround the whole operation by a conversion
to int. Part of the problem is fixed in mainline. However
--- Comment #11 from manu at gcc dot gnu dot org 2008-03-31 11:03 ---
Actually as a user I would find clearer a warning such:
warning: initialization of 'signed char *' from incompatible pointer type 'char
*'
so CONFIRMED.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #3 from manu at gcc dot gnu dot org 2008-04-01 02:53 ---
(In reply to comment #2)
If the size_t given to memcpy is truncated, that does not overwrite a buffer.
But if the size_t given to malloc is truncated, that is a pretty surefire way
to find a security issue.
I
--- Comment #1 from manu at gcc dot gnu dot org 2008-03-27 14:14 ---
Confirmed in trunk and GCC 4.3.0
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-23 14:07 ---
(In reply to comment #2)
Using -Wconversion helps with getting the warning, but it also causes warnings
for normal common things like foo(2*0.5). While foo(NULL) is almost certainly
Hmm, 2*0.5 should be folded
--- Comment #5 from manu at gcc dot gnu dot org 2008-03-23 19:43 ---
(In reply to comment #4)
Otherwise, whether this is
worth warning or a nuisance is a matter of opinion.
True. So, is there any example where use of NULL / __null in a non-pointer
context is a good idea
--- Comment #7 from manu at gcc dot gnu dot org 2008-03-23 22:17 ---
(In reply to comment #6)
Yes. Consider you have code like this:
void foo(void* bar); // a function somewhere
...
foo( NULL ); // you call it
...
Now consider you want to add an overload foo(int). Now
--- Comment #6 from manu at gcc dot gnu dot org 2008-03-20 23:26 ---
(In reply to comment #2)
In mainline, -pedantic-errors is needed. That seems weird to me, maybe Maunel
can help here. On the other hand, a problem with library code seems also
likely.
Why is it weird to need
--- Comment #8 from manu at gcc dot gnu dot org 2008-03-20 23:54 ---
OK. I see now what the problem is: -pedantic nothing, -pedantic-errors gives an
error. The pedantic warning is in a system header, so it doesn't get emitted.
When using -pedantic-errors, it is an error, so it gets
--- Comment #9 from manu at gcc dot gnu dot org 2008-03-20 23:56 ---
Reopened. There is a bug here. The only difference between -pedantic and
-pedantic-errors should be the type of diagnostic, not the amount. This bug was
latent in diagnostics.c. Probably not a regression.
--
manu
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-14 09:36 ---
(In reply to comment #2)
This is the design of warn_unused_result, you cannot ignore the value,
that is why casting to void does not work.
I agree with the reporter. There should be a way to tell the compiler
--- Comment #1 from manu at gcc dot gnu dot org 2008-03-12 15:05 ---
Bugzilla is not the appropriate place to seek opinions, [EMAIL PROTECTED] would
be a better place. This has been discussed already and there was some consensus
about splitting the warnings about precedence of operators
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-11 00:34 ---
This seems to be caused also by Diego's patch to Wtype-limits as bug 35400 (not
sure whether it is an exact duplicate).
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-10 00:37 ---
@Adam,
If you think that something is wrong in the documentation, please point out
exactly which text should be removed and what should be added. Also, feel free
to submit a documentation patch: http://gcc.gnu.org
--- Comment #4 from manu at gcc dot gnu dot org 2008-03-10 00:52 ---
(In reply to comment #2)
Actually, I like that response. I might try to use it myself next time one of
our customers reports a problem.
I guess that your contracted GCC support developers may give you a reply
--- Comment #17 from manu at gcc dot gnu dot org 2008-03-04 20:29 ---
Subject: Bug 28322
Author: manu
Date: Tue Mar 4 20:28:52 2008
New Revision: 132870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132870
Log:
2008-03-04 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #8 from manu at gcc dot gnu dot org 2008-03-03 10:56 ---
This is fixed for 4.4 by introducing permerror which makes -fpermissive
completely independent of -pedantic and -pedantic-errors.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from manu at gcc dot gnu dot org 2008-03-02 15:19 ---
The patch for gcc 4.3 was a duplicate of the patch for gcc 4.2. The correct
patch for gcc 4.3 is here:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00094.html
(thanks to Matthias Klose for noticing
--- Comment #7 from manu at gcc dot gnu dot org 2008-03-02 15:46 ---
Subject: Bug 24924
Author: manu
Date: Sun Mar 2 15:45:29 2008
New Revision: 132817
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132817
Log:
2008-03-02 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #15 from manu at gcc dot gnu dot org 2008-03-01 16:36 ---
(In reply to comment #13)
Thanks a lot for taking the time to write a patch for this. I do have one
question: if I'm reading the patch correctly, this postpones warnings about
unrecognised options not just for -Wno
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-29 00:12 ---
(In reply to comment #0)
This is a regression probably introduced roughly three or four days ago,
unless it's due to a change in the codebase I'm building (which is Wine):
...gcc -Wtype-limits -O2 action.i
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-27 09:00 ---
This just needs someone with the time and willingness to implement it.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2008-02-27 12:34 ---
Patches for older branches have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01357.html
I hope they are useful and don't break anything ;-)
If there is nothing else to do in this PR, I will close
801 - 900 of 1559 matches
Mail list logo
