--- Comment #29 from manu at gcc dot gnu dot org 2008-11-18 15:21 ---
There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01117.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from manu at gcc dot gnu dot org 2008-11-18 15:43 ---
(In reply to comment #30)
> Thanks Manuel. I'm not sure that this is technically a regression, but in any
> case I consider it a serious problem and really hope we can have a fix for
> 4.4.0.
I submi
--- Comment #33 from manu at gcc dot gnu dot org 2008-11-18 16:05 ---
(In reply to comment #32)
> (In reply to comment #31)
> > I submitted the patch long ago. We are in regressions-only mode. This is
> > not a
> > regression. Not sure what else you want me to
--- Comment #1 from manu at gcc dot gnu dot org 2009-01-24 01:40 ---
Quoting the FAQ at http://gcc.gnu.org/wiki/NewWconversion#faq
Why Wconversion is not enabled by -Wall or at least by -Wextra?
Implicit conversions are very common in C. This tied with the fact that there
is no data
--- Comment #2 from manu at gcc dot gnu dot org 2009-01-24 15:56 ---
H.J. Lu, please, commit it as obvious and close this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2009-01-24 16:05 ---
I am almost sure that this is CCP again assuming that the undefined value is
the same as the constant assigned, hence x++ is converted to 0++. This can be
checked using -fdump-tree-all-all-lineno.
If so, a duplicate
--- Comment #13 from manu at gcc dot gnu dot org 2009-01-30 16:11 ---
(In reply to comment #12)
>
> For source codes [a-k]*, there where 906 occurrences of the "set but
> not used" warning from Intel C/C++.
>
@dcb
I think nobody is discussing that we would
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 ---
Subject: Bug 28152
Author: manu
Date: Mon May 4 12:47:53 2009
New Revision: 147097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147097
Log:
2009-05-04 Manuel Lopez-Ibanez
PR c++/
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from manu at gcc dot gnu dot org 2009-05-13 23:18 ---
Subject: Bug 36674
Author: manu
Date: Wed May 13 23:17:55 2009
New Revision: 147504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147504
Log:
2009-05-14 Manuel Lopez-Ibanez
PR cpp/3667
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-13 23:19 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-15 09:11 ---
Does it happen on trunk?
The testcase is too big.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-15 20:08 ---
Subject: Bug 16302
Author: manu
Date: Fri May 15 20:08:21 2009
New Revision: 147596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147596
Log:
2009-05-15 Manuel López-Ibáñez
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-15 20:10 ---
FIXED for GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-15 20:13 ---
Benjamin, note that -Wlogical-op will be enabled by -Wextra in GCC 4.5.
I am willing to give it a try to fix this before 4.5 is released. However, I
cannot reproduce this problem, so please, provide a preprocessed
--- Comment #5 from manu at gcc dot gnu dot org 2009-05-17 16:39 ---
FIXED per previous comment.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2009-05-17 17:11 ---
This patch seems to fix the problem and still warn for the interesting cases.
Could you all test it in your targets? I can only test
x86-64-unknown-linux-gnu.
Index: gcc/c-common.c
--- Comment #13 from manu at gcc dot gnu dot org 2009-05-17 20:47 ---
If GCC does not want to be warned about
if (!x && x)
then the warning is not useful for GCC. Then take it out of -Wextra. But it is
definitely useful for others, and it found a bug in IRA.
--
http://gcc
--- Comment #18 from manu at gcc dot gnu dot org 2009-05-18 23:13 ---
The following patch moves the warning out of Wextra. I haven't tested it,
though.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (rev
--- Comment #25 from manu at gcc dot gnu dot org 2009-05-19 19:29 ---
Subject: Bug 40172
Author: manu
Date: Tue May 19 19:29:27 2009
New Revision: 147717
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147717
Log:
2009-05-19 Manuel López-Ibáñez
PR c/4
--- Comment #26 from manu at gcc dot gnu dot org 2009-05-19 20:29 ---
The case in toplev.c cannot be fixed without tracking macro expansions somehow,
but I wonder why it warns (multiple times!) for this case:
> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or�
--- Comment #4 from manu at gcc dot gnu dot org 2009-05-20 13:12 ---
(In reply to comment #2)
> I'd suspect this to be a related to Jakub's recent changes applied for PR39666
> (i.e. r147136)? Does your testcase work for r147135?
>
On the contrary, I think this i
--- Comment #22 from manu at gcc dot gnu dot org 2009-06-17 12:00 ---
This bug is about not warning for an empty loop (the empty loop is removed and
there is no warning). Since we don't care (enough to find a fix) about this
case, this bug is considered INVALID.
--
manu at gc
--- Comment #2 from manu at gcc dot gnu dot org 2009-06-17 12:02 ---
No, it is not. There is no loop here, this is CCP assuming that res is 0
always.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
... so this is actually a duplicate of bug 18501.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from manu at gcc dot gnu dot org 2009-06-17 12:09 ---
(In reply to comment #28)
> We are not going to fix this.
>
Why? There are many ways to alleviate this. Doing some warnings in the
front-ends, such LLVM does is one. Or propagate some "uninitialized&quo
--- Comment #31 from manu at gcc dot gnu dot org 2009-06-17 12:17 ---
(In reply to comment #30)
> (In reply to comment #28)
> > We are not going to fix this.
> >
>
> Why? There are many ways to alleviate this. Doing some warnings in the
> front-ends, s
--- Comment #33 from manu at gcc dot gnu dot org 2009-06-17 13:25 ---
(In reply to comment #32)
> We can only fix it with the chance of raising more spurious warnings. One
> reason why we run the "may be used uninitialized" pass very late.
The solution of moving the p
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-18 08:16 ---
The difference is what GCC does/does not to detect/hide the warning.
Here, and in 18051, the CCP pass assumes a value for the uninitialized
variable, and hence, the uninit use disappears, so no warning can occur.
In
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-18 16:28 ---
(In reply to comment #4)
> It is an uninitialized use in an exception handler.
Is it an explicit exception handler? Or a compiler-generated?
In any case, it looks like the code is actually executed, so it may well
--- Comment #6 from manu at gcc dot gnu dot org 2009-06-18 16:30 ---
This is marked as a 4.4 regression. Does it happen in trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
--- Comment #7 from manu at gcc dot gnu dot org 2009-06-18 16:43 ---
The warning was removed on purpose per user request, so this is WONTFIX.
We are sorry about the inconvenience this causes to you. We humbly suggest you
consider using a more modern editor, for example emacs, which
--- Comment #36 from manu at gcc dot gnu dot org 2009-06-23 00:12 ---
(In reply to comment #35)
>
> so, what are these? Once we removed the uninitialized use (CCP) we cannot
> recover the information.
We usually do not remove the uninitialized use but assume a value for the
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-25 20:52 ---
GCC 4.5 produces nothing with -Wall -O2. With -Wstrict-aliasing=1 it says:
pr40517.c:4514:8: warning: dereferencing type-punned pointer might break
strict-aliasing rules
pr40517.c:4536:6: warning: dereferencing type
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:41 ---
We can add an option Wunused-result that controls the warnings.
Wno-unused-result and -Werror=unused-result will then work as expected.
Index: gcc/c-common.c
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:49 ---
This seems the exact definition of caret diagnostics.
*** This bug has been marked as a duplicate of 24985 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-02 23:49 ---
*** Bug 40228 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-03 00:25 ---
(In reply to comment #5)
> Manuel, pardon the naive question: are we getting closer to fixing this? I'm
> asking because I saw patches about column numbers and wondered if that really
> means that very
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-06 11:21 ---
This is FIXED in GCC 4.4. There may be a 4.3.4 release but this is not a
regression and nobody seems interested in investigating whether it can be fixed
with a minimal patch. So I am closing it as FIXED.
If you can
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-06 13:19 ---
The root cause is a combination of inline and copy-rename. Copy rename has the
following code:
/* Never attempt to coalesce 2 user variables unless one is an inline
variable. */
if (!ign1 &&am
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-06 16:48 ---
We could add an OPT_Wdefault that replaces 0 in pedwarn(loc, 0, "message"),
then -Werror=default would turn all default warnings into errors. And
-Wno-default will turn off default warnings that cannot be
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-07 10:25 ---
(In reply to comment #5)
>
> Thus code is undefined you have an acess of a char array as a struct.
> Yes you are only taking the address of an element but it is still
> considered an acess by the stand
--- Comment #29 from manu at gcc dot gnu dot org 2009-07-07 22:18 ---
Subject: Bug 31246
Author: manu
Date: Tue Jul 7 22:18:35 2009
New Revision: 149354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149354
Log:
2009-07-08 Manuel López-Ibáñez
PR c
--- Comment #30 from manu at gcc dot gnu dot org 2009-07-07 22:20 ---
FIXED in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-07 22:42 ---
I cannot reproduce this in GCC 4.4.0 or GCC 4.5 revision 149265. This was
probably FIXED at some moment but the testcase is too large for the testsuite.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 13:25 ---
(In reply to comment #3)
>
> Note that getInt is completely inlined and there is no location involving
> that function available anymore :/ The difficulties of C++ and late
> diagnostics ...
D
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-08 13:28 ---
I am going to close this as FIXED, since it cannot be reproduced anymore. If
anyone manages to reproduce it in GCC 4.5, please reopen.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 21:34 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Above code doesn't compile:
>
> Yes it should not be compile. The error message has been improved to tell you
> what the problem is
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 22:08 ---
Are there some cases where a declaration such T x = y can be considered an use
of 'x' by itself?
The following patch warns for this, but it also produces warnings for some
testcases in the testsuite.
Ind
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-09 09:25 ---
Is this mandated to be an error by the standard? Perhaps GCC could just pedwarn
and add the ';' itself, and compile just fine.
Otherwise, I might add a hint:
note: either add ';' or open a b
--- Comment #144 from manu at gcc dot gnu dot org 2009-07-09 15:20 ---
I added in the URL field the relevant section in the GCC manual.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2009-07-09 15:35 ---
@Jacob,
The C/C++ standards have some precise rules of what can and cannot be done
about pointer casts.
See
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html#index-fstrict_002daliasing-749
See also
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-09 15:55 ---
Thanks, it also happens in current trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from manu at gcc dot gnu dot org 2009-07-10 07:27 ---
Subject: Bug 25509
Author: manu
Date: Fri Jul 10 07:27:32 2009
New Revision: 149458
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149458
Log:
2009-07-10 Manuel López-Ibáñez
PR 25509
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-10 07:27 ---
Subject: Bug 40614
Author: manu
Date: Fri Jul 10 07:27:32 2009
New Revision: 149458
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149458
Log:
2009-07-10 Manuel López-Ibáñez
PR 25509
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-10 07:29 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #24 from manu at gcc dot gnu dot org 2009-07-10 07:29 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #7 from manu at gcc dot gnu dot org 2009-07-10 11:50 ---
(In reply to comment #6)
> This is PR39214 in C++ copy of that stuff. Will test and commit as obvious.
>
Please, also add the testcase. Bonus points for factoring out the parts that
are shared between the C
--- Comment #24 from manu at gcc dot gnu dot org 2009-07-13 06:44 ---
(In reply to comment #23)
> Btw, since a couple of days the warning is back :-)
That probably means a regression in the optimizers. Can you identify the
revision?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-14 14:04 ---
There is a FAQ for the new Wconversion:
http://gcc.gnu.org/wiki/NewWconversion#faq
It should answer users' concerns.
As for Wall, we have users requesting less warnings from Wall and users
requesting more. We t
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-14 20:55 ---
Andrew, what you say is true, but in this case the warning is not very useful.
I'd prefer to warn only when the operator is larger than the target of the
assignment. I would like to hear other opinions.
--
ma
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-14 20:56 ---
Joseph, could you comment on this?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-14 22:30 ---
Then, let's keep this around as an enhancement request.
--
manu at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from manu at gcc dot gnu dot org 2009-07-16 22:30 ---
Subject: Bug 40435
Author: manu
Date: Thu Jul 16 22:29:52 2009
New Revision: 149722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149722
Log:
2009-07-17 Aldy Hernandez
Manuel López-
--- Comment #10 from manu at gcc dot gnu dot org 2009-07-16 22:38 ---
FIXED.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-22 05:19 ---
(In reply to comment #4)
> How come this is still sitting unconfirmed? This is something that involves
> Linux et. al. Using --without-cloog, ppl, or mpc doesn't work right as per
> previous post, so i
--- Comment #15 from manu at gcc dot gnu dot org 2009-07-23 15:35 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01179.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-24 23:40 ---
(In reply to comment #1)
> Dan Berlin, Diego, and I bounced this around on IRC a little. A couple of
> things that came up:
>
> - Diego suggested putting locuses on unshared INTEGER_CSTs as anothe
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 ---
(In reply to comment #2)
> I tried to look for more similar cases. But I couldn't find anything. Not
> that it is all that easy to search for. Neither "error" nor "?" are
> particu
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-27 17:08 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Try grep -e ' error ([^"]' gcc/*.c -A 1
>
> Ah, ok. I tried to search for similar BUGZILLA reports. Not for similar
> case
--- Comment #9 from manu at gcc dot gnu dot org 2009-07-27 18:06 ---
I am not going to work on this. Unsubscribing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-30 11:34 ---
Perhaps it would be better just to remove it in the next GCC 4.4 release (I
guess it has been fixed/removed in GCC 4.5). Telling people not to use it after
they discover it is broken is a bit useless.
--
manu at
--- Comment #16 from manu at gcc dot gnu dot org 2009-07-30 12:02 ---
(In reply to comment #8)
> If anyone cares to repeat my test results, here's a simple test case:
This is not a simple testcase. A simple testcase is a sufficiently small
self-contained compilable code that s
--- Comment #1 from manu at gcc dot gnu dot org 2009-07-31 14:47 ---
This is confirmed in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:40 ---
I am going to close this. First I don't know what the C++ standard says and
there are too many open and unconfirmed bugs for anyone to care about this.
--
manu at gcc dot gnu dot org changed:
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:51 ---
What is the bad code generated? What were you expecting? Can you remove any
unused classes and functions from the testcase. It is excessively large.
Thanks.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:42 ---
Reported against 3.4.4, not reproducible in trunk, no answer in more than one
year.
Closing as WORKSFORME.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-31 15:11 ---
Geir, have you run the testcase with other compilers? What is the result?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-31 15:13 ---
Is this really a bug or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 16:46 ---
A reduced testcase:
extern inline const char *
_strnchr (const char *str, char c, unsigned size);
extern inline void *
_memcpy (void *dst, const void *src, const unsigned size)
{
if (__builtin_constant_p (size
--- Comment #5 from manu at gcc dot gnu dot org 2009-08-03 14:07 ---
(In reply to comment #3)
> Created an attachment (id=18289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18289&action=view) [edit]
> gcc45-pr40943.patch
>
> Untested fix. It breaks unini
--- Comment #15 from manu at gcc dot gnu dot org 2009-08-04 09:22 ---
Testcase in comment #9 does not produce any output anymore.
Testcase in comment #10 produces:
/home/manuel/src/pr15179.C:8:18: error: type A is not derived from type
B
/home/manuel/src/pr15179.C:8:23: error
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-04 09:34 ---
For the first testcase, A could well be defined without type, so "const A"
would be valid. So we definitely need to emit another error before '&' but the
current one is misleading. Perhaps "
--- Comment #15 from manu at gcc dot gnu dot org 2009-08-04 10:52 ---
(In reply to comment #14)
> (In reply to comment #13)
>
> > We need someone to write the patch. Just that.
>
> I've got some spare time now, so I'd like to have a go.
If you want yo
--- Comment #12 from manu at gcc dot gnu dot org 2009-08-04 15:51 ---
Subject: Bug 16696
Author: manu
Date: Tue Aug 4 15:51:12 2009
New Revision: 150461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150461
Log:
2009-08-04 Manuel López-Ibáñez
PR c++/
--- Comment #13 from manu at gcc dot gnu dot org 2009-08-04 15:52 ---
FIXED in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-04 16:02 ---
This is still valid and it does not depend on -fpermissive. It would be
interesting to see what is the output from other C++ compilers.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-04 16:23 ---
Confirmed in trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #8 from manu at gcc dot gnu dot org 2009-08-04 22:42 ---
(In reply to comment #7)
>
> It might be an improvement if GCC gave different diagnostics for the case
> where
> a suitable conversion sequence exists but cannot be used because it would
> create
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 22:47 ---
We should really upgrade bugzilla to version 3.0
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 23:32 ---
The C parser points to the start of the second declaration, which is not very
good either.
pr36888.c:5:1: error: two or more data types in declaration specifiers
In the c-parser, we can probably special case the
--- Comment #32 from manu at gcc dot gnu dot org 2009-08-04 23:42 ---
Since the patch was reverted, this is still a regression in all open branches.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 23:51 ---
Subject: Bug 36069
Author: manu
Date: Tue Aug 4 23:51:07 2009
New Revision: 150471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150471
Log:
2009-08-05 Manuel López-Ibáñez
PR c++/
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-04 23:52 ---
FIXED in GCC 4.5. Thanks for the report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-05 10:01 ---
By the way, we would prefer a preprocessed testcase, as minimal as possible.
See http://gcc.gnu.org/bugs.html#report
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 10:16 ---
At the moment the parser detects and reports the error, it doesn't know that it
is parsing an array subscript. We could test for typical errors before trying
to parse the expression but that would pessimize valid
--- Comment #21 from manu at gcc dot gnu dot org 2009-08-05 12:09 ---
Are there any failing testcases for this PR? Perhaps we can turn this into a
meta-bug, or if there are no testcases right now, it would be better to close
it (we have already enough open PRs).
--
http
--- Comment #25 from manu at gcc dot gnu dot org 2009-08-05 13:21 ---
If anyone has any hint on where this could be caught, suggestions are welcome.
The explanation of Alexandre Oliva in comment #8 is totally obscure to me and
perhaps outdated given the age of this PR.
--
manu at
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-05 13:55 ---
What happens when a function must have a particular return type because it is
accessed through a pointer, but we want to mark it as noreturn?
Example: gcc/java/jcf.h (jcf_unexpected_eof)
I am not sure this warning is
1 - 100 of 1573 matches
Mail list logo
