--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-31 20:13 ---
That's because the whole foo function doesn't have any side-effects, so it is
optimized away completely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
--- Comment #6 from jellegeerts at gmail dot com 2010-08-31 20:14 ---
It also happens in functions that do have side-effects. I can give you an
example if you want?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
When compiling a file with the `-Wuninitialized' flag, but without `-O', one
does not get a warning from GCC 4.5.1 (and `-Wuninitialized' has no effect).
GCC should output something like `cc1.exe: warning: -Wuninitialized is not
supported without -O', like GCC 3.4.5 did.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 20:19 ---
GCC 3.4.5 did.
That is because GCC 4.5 and above support -Wuninitialized at -O0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:23 ---
I already reasoned that that might have been the case, but it seems false,
because if I compile the following snippet with GCC 4.5.1 with the command `gcc
newtest.c -std=c99 -Wall', I get no warning about the
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:24 ---
Reopening bug.
--
jellegeerts at gmail dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 ---
#include stdio.h
int main(void)
{
int i;
printf (%d\n, i);
return 0;
}
Is warned about with -Wuninitialized at -O0. We don't warn about the uses that
might be used unitialized. That means if i is
--- Comment #26 from hjl dot tools at gmail dot com 2010-08-31 20:30
---
(In reply to comment #15)
Created an attachment (id=21607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21607action=view) [edit]
rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY
This is
--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:32 ---
Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is,
even though the function foo() may have side-effects.
#include stdio.h
static int array[32];
#if 0 // If '#if 1' is used, GCC warns
--- Comment #5 from jellegeerts at gmail dot com 2010-08-31 20:36 ---
With `gcc -std=c99 -Wuninitialized -O0' I get no warning for the following code
snippet (I do with `-O1' though), so it still seems GCC 4.5.1 should warn about
`-O' not being specified.
#include stdio.h
int
--- Comment #8 from manu at gcc dot gnu dot org 2010-08-31 20:37 ---
(In reply to comment #7)
Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is,
even though the function foo() may have side-effects.
No, the function below does not have any side-effects. The
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-31 20:37 ---
so it still seems GCC 4.5.1 should warn about `-O' not being specified.
No, I showed an example of where it does warn without -O.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:39 ---
I am pointing out a case where it does not warn (and it seems to me that it
should); what is your point?
--
jellegeerts at gmail dot com changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-31 20:40 ---
(In reply to comment #7)
I am pointing out a case where it does not warn (and it seems to me that it
should); what is your point?
My point is that you should open a different bug that says we should warn about
--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:45 ---
I get that point, and I might open another bug report for that case, sure.
Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was the
point of this bug report. That the `-O0' flag doesn't work is
--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:47 ---
Okay. :)
Though, why does GCC warn when we have `#if 1', and not if we have `#if 0'?
Just curiosity...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-08-31 20:49
---
(In reply to comment #9)
Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was
the
point of this bug report. That the `-O0' flag doesn't work is another story.
And I showed a case where
--- Comment #10 from jellegeerts at gmail dot com 2010-08-31 20:49 ---
Also, it seems a bit questionable to not warn when it is clearly(?) not the
developers intent to use an uninitialized variable. What is the rationale
behind this? Is it a pragmatic thing?
--
--- Comment #11 from manu at gcc dot gnu dot org 2010-08-31 20:53 ---
(In reply to comment #8)
(In reply to comment #7)
I am pointing out a case where it does not warn (and it seems to me that it
should); what is your point?
My point is that you should open a different bug that
--- Comment #11 from jakub at gcc dot gnu dot org 2010-08-31 20:53 ---
Because when foo is not static, it has to be compiled. If it is static, GCC
figures it is a pure function (only reads memory and arguments and computes
from it its return value) and as the result in main of the
--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:54 ---
Thanks. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:59 ---
Sorry Andrew, misinterpreted some things you said. I understand now that you
meant that normally everything should work as expected.
@Manuel,
So, perhaps then this bug report is at least sort of valid? It seems that
--- Comment #13 from manu at gcc dot gnu dot org 2010-08-31 21:07 ---
(In reply to comment #12)
Sorry Andrew, misinterpreted some things you said. I understand now that you
meant that normally everything should work as expected.
@Manuel,
So, perhaps then this bug report is at
--- Comment #14 from jellegeerts at gmail dot com 2010-08-31 21:16 ---
(In reply to comment #13)
(In reply to comment #12)
@Manuel,
So, perhaps then this bug report is at least sort of valid? It seems that to
get `-Wuninitialized' to *fully* work, one would need at least `-O1'?
I got this error when building an i386-apple-darwin cross compiler on my
x86_64-fedora-linux-gnu. It compiles everything up to the command
ranlib libbackend.a and a little after, then the sub-directory configure script
fails.
I configured it and made it with this:
[...@chessman
--- Comment #1 from leo dot izen at gmail dot com 2010-08-31 21:17 ---
Created an attachment (id=21623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21623action=view)
configure output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
--- Comment #2 from leo dot izen at gmail dot com 2010-08-31 21:18 ---
Created an attachment (id=21624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21624action=view)
make output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-31 21:27 ---
./configure
First don't build in the source directory.
Second can you attach
/home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log
?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #15 from manu at gcc dot gnu dot org 2010-08-31 21:34 ---
(In reply to comment #14)
depend on which optimization passes are run (and their order). See
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on
the issues involved and existing bugs.
--- Comment #16 from jellegeerts at gmail dot com 2010-08-31 21:38 ---
Thanks for the explanation.
I understand it's a hard thing to fix. It's a bit of a sad situation, and has
been for quite a while, unfortunately. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
--- Comment #4 from leo dot izen at gmail dot com 2010-08-31 22:08 ---
(In reply to comment #3)
./configure
First don't build in the source directory.
Second can you attach
/home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log
?
I changed it so I
--- Comment #5 from leo dot izen at gmail dot com 2010-08-31 22:09 ---
Created an attachment (id=21625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21625action=view)
new configure output
--
leo dot izen at gmail dot com changed:
What|Removed
--- Comment #6 from leo dot izen at gmail dot com 2010-08-31 22:09 ---
Created an attachment (id=21626)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21626action=view)
new make log
--
leo dot izen at gmail dot com changed:
What|Removed |Added
--- Comment #17 from jakub at gcc dot gnu dot org 2010-08-31 22:26 ---
Manuel, can you back up your claims about the C FE being slow with some
numbers? I don't remember the C FE ever being a time issue recently, of course
C++ is a different story.
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-31 22:28 ---
Can you attach
/home/Leo/i386appledarwinbuild/i386-apple-darwin/libgcc/config.log ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
Compiler output:
$ gcc -O1 -ftree-vectorize -fnon-call-exceptions testcase.C
testcase.C: In constructor 'B::B()':
testcase.C:17:1: error: BB 2 can not throw but has an EH edge
testcase.C:17:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 22:39 ---
Created an attachment (id=21627)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21627action=view)
reduced testcase
$ gcc -O1 -ftree-vectorize -fnon-call-exceptions pr45470.C
--
--- Comment #18 from manu at gcc dot gnu dot org 2010-08-31 22:44 ---
(In reply to comment #17)
Manuel, can you back up your claims about the C FE being slow with some
numbers? I don't remember the C FE ever being a time issue recently, of
course
C++ is a different story.
I mean
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-31 22:47 ---
Subject: Bug 45457
Author: jakub
Date: Tue Aug 31 22:47:25 2010
New Revision: 163705
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163705
Log:
PR preprocessor/45457
* expr.c (parse_defined):
--- Comment #8 from leo dot izen at gmail dot com 2010-08-31 22:59 ---
Created an attachment (id=21628)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21628action=view)
the config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-31 23:01 ---
/home/Leo/i386appledarwinbuild/./gcc/as: line 83: exec: : not found
The as is not being found.
checking for as... no
checking for i386-apple-darwin-as... no
You don't have the cross binutils/cctools installed.
Command line:
$ g++ -O2 testcase.h
$ g++ -O2 testcase.C -fno-strict-aliasing
Compiler output:
$ g++ -O2 testcase.h
$ g++ -O2 testcase.C -fno-strict-aliasing
testcase.h: In constructor 'Aanonymous ::A() [with int anonymous = 0]':
testcase.h:17:12: instantiated from here
testcase.h:13:5: internal
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 23:14 ---
The PCH should be rejected for the differences in strict-aliasing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zsojka at seznam dot cz 2010-08-31 23:16 ---
Created an attachment (id=21629)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21629action=view)
reduced header file
#include typeinfo
can be replaced with:
namespace std { struct type_info { }; }
The second part of
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-31 23:23 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from mikael at gcc dot gnu dot org 2010-08-31 23:36 ---
(In reply to comment #5)
(In reply to comment #2)
Try compiling with -fdump-tree-original and inspecting the
expected argument lists. You really don't want to use a
function here. Use a subroutine.
Command line:
$ gcc -O1 -fschedule-insns2 -fselective-scheduling2 testcase.c
Compiler output:
$ gcc -O1 -fschedule-insns2 -fselective-scheduling2 testcase.c
testcase.c: In function 'foo':
testcase.c:18:1: internal compiler error: in move_op_ascend, at
sel-sched.c:6124
Please submit a full bug
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 23:58 ---
Created an attachment (id=21630)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21630action=view)
reduced testcase
$ gcc -O1 -fschedule-insns2 -fselective-scheduling2 pr45472.c
--
--- Comment #27 from mrs at gcc dot gnu dot org 2010-09-01 00:25 ---
I don't think MAIN_STACK_BOUNDARY needs to be set, nor will it help to set it.
The alignment is set up by the crt runtime, and just to call to main, the
alignment of the stack must be 128, before we issue the call.
Compiler output:
$ gcc testcase.C
testcase.C:11:8: internal compiler error: in dfs_walk_once, at cp/search.c:1659
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r163636 - crash
r162940 - crash
r161659
--- Comment #1 from zsojka at seznam dot cz 2010-09-01 00:32 ---
Created an attachment (id=21631)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21631action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45473
--- Comment #28 from hjl dot tools at gmail dot com 2010-09-01 01:08
---
(In reply to comment #27)
I don't think MAIN_STACK_BOUNDARY needs to be set, nor will it help to set
it.
The alignment is set up by the crt runtime, and just to call to main, the
alignment of the stack must
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 01:10 ---
It is caused by revision 163260:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00471.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-09-01 02:10
---
Update: More responses in comp.lang.fortran bring up the point that if
trim(line)
is supposed to return a temporary, the code might be conforming. Seems that
the
situation is not clear...
Where in the
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 02:29 ---
It is caused by revision 162008:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00362.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 03:03 ---
It is caused by revision 147282:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00256.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-09-01
04:02 ---
(In reply to comment #28)
If you don't set MAIN_STACK_BOUNDARY to 128, gcc may
align stack in main.
I am seeing some instability in the testsuite results when I don't redefine
MAIN_STACK_BOUNDARY to
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 04:32 ---
I recently implemented a custom memcpy for ScummVM. I didn't notice the
standard memcpy using lwl and lwr. In any case, how would memcpy do it any
better? Unless you're referring to the new memcpy inlining in newer
On Aug 31, 2010, at 9:32 PM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01
04:32 ---
I recently implemented a custom memcpy for ScummVM. I didn't notice
the
standard memcpy using lwl and lwr. In any
--- Comment #7 from pinskia at gmail dot com 2010-09-01 04:41 ---
Subject: Re: Bad optimization in -O3 sometimes
On Aug 31, 2010, at 9:32 PM, yotambarnoy at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01
04:32
--- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 ---
Unfortunately, a lib based solutions are difficult for me to implement. The
reason is that the current PSP SDK uses newlib. I can probably change my
personal toolchain with some work, but then it's a custom
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-09-01
05:34 ---
With only gcc-pr45234-2.patch at r163712 , I am seeing the following
regressions...
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal
compiler error)
FAIL:
101 - 162 of 162 matches
Mail list logo
