--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 16:18 ---
This is an interaction between SRA deciding to create separate variables for
testval and unusedval because of the copy and DCE deciding whether to remove
all references to unusedval because of the call.
The copy
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-07 16:27 ---
This is just another case that would require conditional PHIs. I am not marking
it as a duplicate of bug 36550, because this case is harder than then typical:
if(q) p=1;
something()
if(q) use(p);
Therefore, it may
--- Comment #4 from manu at gcc dot gnu dot org 2009-02-07 16:30 ---
Two years without testcase. I cannot reproduce. Probably a duplicate. Marked as
INVALID. Please, reopen if you have a reproducible testcase obtained following
http://gcc.gnu.org/bugs.html#report
--
manu at gcc dot
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 20:18 ---
This still fails in GCC 4.4
icc accepts the code in strict mode, so I guess this is rejects-valid.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from manu at gcc dot gnu dot org 2009-02-07 20:23 ---
There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00970.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-07 20:46 ---
This is a missing diagnostic.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from manu at gcc dot gnu dot org 2009-02-07 20:54 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00874.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from manu at gcc dot gnu dot org 2009-02-07 20:58 ---
(In reply to comment #18)
There were couple of bugs with real C code where warnings are actually useful
-
Yes please. reopen what those that you feel are still valid and add me to the
CC list.
--
http
--- Comment #28 from manu at gcc dot gnu dot org 2009-02-07 21:07 ---
There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00972.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 21:11 ---
This is clearly CCP. Probably a duplicate of 18501, better double check if
18501 is ever fixed.
The reason why uncommenting the block of code brings back the warning is that
CCP cannot assume that foo is just 50
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 21:15 ---
This is an EXACT duplicate of bug 18501. CCP just assumes that foo is 8 always
and just removes foo completely.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-07 21:15 ---
*** Bug 30575 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2009-02-07 21:21 ---
This wasn't a duplicate of bug 22456
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-07 21:29 ---
This is a duplicate of 18501. CCP assumes y is always 23.
Reordering passes just changes the set of false negatives/positives. For
example, if you move the warning before CCP, then you get a warning for this
case
--- Comment #25 from manu at gcc dot gnu dot org 2009-02-07 21:29 ---
*** Bug 30856 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from manu at gcc dot gnu dot org 2009-02-07 21:33 ---
(In reply to comment #19)
(In reply to comment #18)
There were couple of bugs with real C code where warnings are actually
useful -
Yes please. reopen what those that you feel are still valid and add me
--- Comment #14 from manu at gcc dot gnu dot org 2009-02-08 15:46 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00285.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-08 15:51 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00806.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-08 15:54 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01118.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-08 15:56 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00875.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-08 23:07 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00308.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-09 15:35 ---
After inlining, pp is initialized to 0.
# BLOCK 3 freq:9550, starting at line 0
# PRED: 10 [95.5%] (true,exec)
[/home/manuel/pr36823.c : 23] D.1611_4 = [/home/manuel/pr36823.c : 23]
pD.1607_2-bD.1592;
ppD
--- Comment #4 from manu at gcc dot gnu dot org 2009-02-09 15:41 ---
We cannot reproduce the bug you reported with a recent revision of GCC 4.4.
If you still see the problem, please reopen. Thanks.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-09 15:56 ---
This testcase is too big to see clearly what is going on. A reduced testcase
would be appreciated (preferably with just 1 function).
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-09 16:06 ---
This works in GCC 4.1, 4.3 and 4.4, so this is either a regression (that
probably will not be fixed before 4.2 is closed) or it is not a regression and
should be closed as FIXED already in trunk.
--
manu at gcc dot
--- Comment #10 from manu at gcc dot gnu dot org 2009-02-09 16:13 ---
I cannot reproduce this with current GCC 4.4
Also, the testcase is too big.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2009-02-09 16:15 ---
Actually, I am going to close it as WORKSFORME, but if you can reproduce this
with a GCC later than revision 143971 (even in this huge testcase), please
reopen. Thanks for the report.
--
manu at gcc dot gnu dot
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
BugsThisDependsOn
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-11 22:13 ---
We need a reproducible preprocessed testcase.
See http://gcc.gnu.org/bugs.html#detailed
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-11 23:04 ---
Confirmed. I have a patch for this for 4.5.
The new wording will say:
warning: logical 'or' applied to non-boolean constant.
Are you satisfied with this?
BTW, why no warning for this?
resp == 0 0
Naturally
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-12 00:25 ---
Is there anything that remains to be done here?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-12 11:22 ---
At the moment of warning, the compiler does not know that the uninitialized
variables are only used if they have been set before. Hence, the warning.
This will require conditional PHIs (or some other way to detect
--- Comment #7 from manu at gcc dot gnu dot org 2009-02-12 11:22 ---
*** Bug 39133 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 2009-02-12 14:33 ---
I think this is a reasonable request. Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2009-02-12 14:59 ---
Updating the description. Although anyone would agree that not warning is the
right thing to do, there doesn't seem to be any practical solution for this
problem, so I leave it as unconfirmed.
I wonder if clang/llvm
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-12 15:11 ---
So this is a bug in the C front-end. In any case, it is either a bug or an
enhancement request. So confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-12 15:06 ---
Closed as WONTFIX per Joseph comments. Thanks for the report nonetheless.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from manu at gcc dot gnu dot org 2009-02-12 22:05 ---
(In reply to comment #9)
I do not really understand problem 5 for the case when the only dependancy for
the code-path check is a local variable. In this case the value cannot be
change by any other code than
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-18 13:13 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-18 13:15 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-03-08 03:30 ---
The old behavior was just fine!
You absolutely did not understand what the old -Wconversion did.
http://gcc.gnu.org/wiki/NewWconversion
But if you still want the old behaviour, just use -Wtraditional-conversion
--- Comment #7 from manu at gcc dot gnu dot org 2009-03-08 03:54 ---
(In reply to comment #5)
BTW, my comment was about the C++ frontend. IE:
.../gcc44/bin/g++ -c -Wall -W -Wconversion test.cpp
The code of Wconversion is shared between C and C++ front-ends, so they should
produce
--- Comment #5 from manu at gcc dot gnu dot org 2009-03-10 19:15 ---
(In reply to comment #4)
The previous version of gcc warned when implicit narrowing of doubles to
integral values, such as
double n = 0.05;
int d = n;
when using the -Wall option.
AFAIK
--- Comment #2 from manu at gcc dot gnu dot org 2007-05-25 14:05 ---
(In reply to comment #0)
While this is trivial we should have pride in our great compiler and the
usually great results. Even if there are failures we should still present them
neatly.
If it is trivial, then just
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-28 12:54 ---
Worse, with __builtin_sin(M_PI), I get an error:
test.c:2: error: initializer element is not constant
Maybe this is fixed now in GCC 4.3 by using MPFR.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #7 from manu at gcc dot gnu dot org 2007-05-29 12:26 ---
(In reply to comment #6)
It's a cut down example to demonstrate the problem, not real world code.
Could you provide an example of real-world code where the warning is triggered?
We would prefer minimal but anything
--- Comment #8 from manu at gcc dot gnu dot org 2007-05-29 12:31 ---
(In reply to comment #6)
so, is it still an invalid testcase?
Does the warning show up with -O1 and -O2 ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2007-05-29 12:57 ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #6)
so, is it still an invalid testcase?
Does the warning show up with -O1 and -O2 ?
only with -O3.
That is a bug
--- Comment #27 from manu at gcc dot gnu dot org 2007-05-30 17:23 ---
Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html
before closing as FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Comment #3 from manu at gcc dot gnu dot org 2007-06-04 13:51 ---
Likely, the code for parsing template arguments is not clever enough to stop as
soon as something goes awry and report it correctly.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #50 from manu at gcc dot gnu dot org 2007-06-04 21:12 ---
Subject: Bug 25241
Author: manu
Date: Mon Jun 4 21:11:51 2007
New Revision: 125317
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125317
Log:
2007-06-04 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #28 from manu at gcc dot gnu dot org 2007-06-05 22:25 ---
Subject: Bug 23479
Author: manu
Date: Tue Jun 5 22:25:27 2007
New Revision: 125346
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125346
Log:
2007-06-05 Joerg Wunsch [EMAIL PROTECTED]
PR
--- Comment #51 from manu at gcc dot gnu dot org 2007-06-05 22:30 ---
Subject: Bug 25241
Author: manu
Date: Tue Jun 5 22:30:24 2007
New Revision: 125347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125347
Log:
2007-06-05 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #29 from manu at gcc dot gnu dot org 2007-06-06 11:23 ---
(In reply to comment #28)
(In reply to comment #27)
It is not like GCC is a closed source program either,
you can try to make a fix for the issue too.
Andrew, real world is not so simple ;)
[snip]
c.a. 3
--- Comment #52 from manu at gcc dot gnu dot org 2007-06-06 20:49 ---
Subject: Bug 25241
Author: manu
Date: Wed Jun 6 20:49:09 2007
New Revision: 125505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125505
Log:
2007-06-06 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #30 from manu at gcc dot gnu dot org 2007-06-07 00:31 ---
(In reply to comment #29)
Fixed.
I was waiting for updating http://gcc.gnu.org/gcc-4.3/changes.html before
closing, but whatever...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Comment #53 from manu at gcc dot gnu dot org 2007-06-07 21:01 ---
Subject: Bug 25241
Author: manu
Date: Thu Jun 7 21:01:41 2007
New Revision: 125543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125543
Log:
2007-06-07 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #10 from manu at gcc dot gnu dot org 2007-06-15 14:07 ---
(In reply to comment #7)
Not really because this is a standard GCC option and having it different
between java and other languages is wrong.
http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Warning-Options.html
--- Comment #33 from manu at gcc dot gnu dot org 2007-06-26 14:38 ---
(In reply to comment #31)
Just mentioning: printf() and std::cout need to be updated if the binary
values
are also to be *output*. Any ideas on how or where that is to be done?
As Joerg pointed out
--- Comment #21 from manu at gcc dot gnu dot org 2007-06-30 12:56 ---
Subject: Bug 4076
Author: manu
Date: Sat Jun 30 12:56:43 2007
New Revision: 126144
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126144
Log:
2007-06-30 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR c
--- Comment #22 from manu at gcc dot gnu dot org 2007-06-30 12:58 ---
Fixed for GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32562
--- Comment #54 from manu at gcc dot gnu dot org 2007-06-30 13:03 ---
Subject: Bug 25241
Author: manu
Date: Sat Jun 30 13:02:48 2007
New Revision: 126145
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126145
Log:
2007-06-30 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #55 from manu at gcc dot gnu dot org 2007-06-30 13:06 ---
Subject: Bug 25241
Author: manu
Date: Sat Jun 30 13:06:45 2007
New Revision: 126146
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126146
Log:
2007-06-30 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-03 09:03 ---
(In reply to comment #12)
[Here's what I sent to gcc-patches as a review of this patch:]
Doing this will certainly break many tools which parse the output of GCC,
In the same way that adding any other output
--- Comment #6 from manu at gcc dot gnu dot org 2007-07-04 13:08 ---
(In reply to comment #4)
No idea how to untangle -pedantic from -Wtabs or -Wampersand if
-pedantic-errors has been given, but -Werror has not.
What gfortran should do is that if pedantic enables Wtabs
--- Comment #3 from manu at gcc dot gnu dot org 2007-07-08 10:12 ---
(In reply to comment #0)
testcase, compile with -pedantic-errors (we don't reject it overwise in 4.3):
unsigned char p;
unsigned char p1 = p 512;
Now there is an overflow but only because we optimize the IR
--- Comment #56 from manu at gcc dot gnu dot org 2007-07-08 14:50 ---
Subject: Bug 25241
Author: manu
Date: Sun Jul 8 14:50:37 2007
New Revision: 126461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126461
Log:
2007-07-08 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #57 from manu at gcc dot gnu dot org 2007-07-10 09:17 ---
Subject: Bug 25241
Author: manu
Date: Tue Jul 10 09:17:01 2007
New Revision: 126511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126511
Log:
2007-07-10 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #58 from manu at gcc dot gnu dot org 2007-07-12 22:57 ---
Subject: Bug 25241
Author: manu
Date: Thu Jul 12 22:57:32 2007
New Revision: 126606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126606
Log:
2007-07-12 Manuel Lopez-Ibanez [EMAIL PROTECTED
--- Comment #59 from manu at gcc dot gnu dot org 2007-07-12 23:05 ---
This is fixed for the C front-end.
The C++ front-end just needs to define the prefixes and fix all failures in the
same way that has been done for the C front-end.
The Fortran front-end would require more changes
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-26 13:57 ---
(In reply to comment #12)
I want the warning.
but why the warning is glibc's bug?
Andrew already tried to explain. It is a side-effect of a bug in glibc.
because memset(x,19,0), is buggy code.
I need the warning
--- Comment #15 from manu at gcc dot gnu dot org 2007-07-26 16:58 ---
(In reply to comment #14)
Subject: Re: warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think that is a sensible feature request, am I
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-15 14:22 ---
(In reply to comment #8)
*** Bug 17172 has been marked as a duplicate of this bug. ***
I see that the xfail is still there, so how can this be fixed ?
http://gcc.gnu.org/svn/gcc/trunk/gcc/testsuite/gcc.dg/uninit-B.c
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-15 14:41 ---
I am not so sure this is fixed. I need to double check this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-15 15:02 ---
(In reply to comment #12)
Created an attachment (id=13354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13354action=view) [edit]
patch to preserve uninitialized PHI arguments in CCP
like so. -O -Wall gives
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:05 ---
Diego, I think this is caused by CCP silently merging UNDEFINED PHI nodes. We
could group similar cases into PR18501, don't you think?
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-15 15:21 ---
(In reply to comment #3)
Is it really quite as 22456? That bug is about variable used for initializing
itself, and really strange do-nothing code, while this one is straightforward
use of unitialized variable
--- Comment #35 from manu at gcc dot gnu dot org 2007-08-15 15:23 ---
If there are not going to be more releases of GCC 4.0 or 4.1, I guess we can
close this, no?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:36 ---
Trying to improve the summary to help spot duplicates.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-16 10:19 ---
Some analysis http://gcc.gnu.org/ml/gcc/2007-08/msg00271.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
OtherBugsDependingO 10138
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-16 10:57 ---
Let's simplify this report. This one is now about
int atoi(const char *);
int foo()
{
char buf[10];
return atoi(buf);
}
As comment #3 mentions, this is a combination of
1) Report use of uninitialized array
--- Comment #2 from manu at gcc dot gnu dot org 2007-08-16 11:19 ---
(In reply to comment #1)
At least for languages where 'const' is actually enforced
There is none,
void use(const int *a)
{
a[0] = 5;
}
void foo(void)
{
int i;
use(i);
}
new.c:3: error: assignment
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-16 14:39 ---
I think this is confirmed. Patches welcome!
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 ---
This seems to me a duplicate of PR179. I am going to add a dependency to
remember to check this PR when PR179 gets fixed.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-17 10:15 ---
(In reply to comment #3)
void use(const int *a)
{
int *b = (int*)a;
Andrew, you are right. I tend to forget how fragile is 'const', even in C++.
So, then this is invalid and thus it is PR10138.
--
http
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-17 10:24 ---
(In reply to comment #5)
This is now fixed both in mainline and in 4_2-branch:
32190.C: In function 'int main()':
32190.C:5: error: template argument 1 is invalid
at this point, not being a regression, I think
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 ---
Ivan, would you like to write, test and post the testcase? Once it is approved
I can commit it for you (with your name of course!).
A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you
need
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Nothing is wrong, but to be useful for GCC
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-20 10:26 ---
Is this still valid?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #7 from manu at gcc dot gnu dot org 2007-08-20 14:18 ---
Even simpler testcase:
int foo ()
{
int i = 0;
int j;
if (1 == i)
return j;
return 0;
}
This will only be reliably fixed by building a better SSA representation.
Moving the passes around
--- Comment #5 from manu at gcc dot gnu dot org 2007-08-20 14:47 ---
Andrew, what about functions marked with attribute pure ?
int atoi(const char *) __attribute__ ((pure));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-20 14:49 ---
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C. atoi(const
char *) could always initialize buf[]. However, perhaps it can
--- Comment #12 from manu at gcc dot gnu dot org 2007-08-20 15:03 ---
(In reply to comment #11)
(In reply to comment #10)
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C.
atoi(const
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-20 15:08 ---
(In reply to comment #12)
This testcase has nothing to do with uninitialized variables. If the variable
is 'const' already, then there will never be a warning. Will it produce
segmentation fault for a local
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-20 16:15 ---
(In reply to comment #14)
This is meant to only counter your point that:
'const' does not mean read-only in C++ at all, and much less in C.
atoi(const
char *) could always initialize buf[].
This simply isn't
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-20 16:44 ---
(In reply to comment #16)
(In reply to comment #15)
Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly
able
to initialize buf. (or perhaps, I am still confused).
Since use() (like
--- Comment #18 from manu at gcc dot gnu dot org 2007-08-20 16:46 ---
When I say constant are not propagated I mean the constant value of a
variable such as:
int i=0;
use(i);
foo(i);
Here, GCC does not propagate the value of i to do foo(0). Remove the call to
use
301 - 400 of 1559 matches
Mail list logo
