--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-08-31
07:04 ---
Using the proposed PR36502v2.patch, which eliminates any attempts to change the
default stack boundary handling in gcc trunk, I find the following regressions
at -m32 on x86_64-apple-darwin10...
FAIL: gcc
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-31 08:15 ---
confirmed. I was working on fixing this but you beat my patch to it.
cheers
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-31 09:13 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from andi-gcc at firstfloor dot org 2010-08-31 09:32 ---
Sorry this is not fixed yet, only partially. Still working on the last bits,
in particular passthrough of non LTOed code like assembler functions.
--
andi-gcc at firstfloor dot org changed:
What|R
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE: in |[4.5/4.6 Regression] ICE: in
|add_labels_and_missin
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45457
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45454
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 09:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 ---
Subject: Bug 45455
Author: rguenth
Date: Tue Aug 31 10:01:04 2010
New Revision: 163669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163669
Log:
2010-08-31 Richard Guenther
PR testsuite/45455
Compiler output:
$ gcc -fshort-enums testcase.c
testcase.c: In function 'foo':
testcase.c:12:29: warning: 'enum E' is promoted to 'int' when passed through
'...' [enabled by default]
testcase.c:12:29: note: (so you should pass 'int' not 'enum E' to 'va_arg')
testcase.c:12:29: note: if this code is
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 10:12 ---
Created an attachment (id=21600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21600&action=view)
reduced testcase
$ gcc -fshort-enums pr45461.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-31 11:24 ---
Created an attachment (id=21601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21601&action=view)
gcc46-pr45457.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45457
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2010-08-31 11:26
---
Patch submitted at http://gcc.gnu.org/ml/fortran/2010-08/msg00476.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.5.0 |4.5.0 4.6.0
Summary|-print-file-name doesn't|[4.4 on
This bug was very hard to trace. I'm on the ScummVM dev team and I develop
specifically for the PSP(MIPS). I came across a crash when trying to start one
of our engines. The bug only occurred under very specific circumstances -- I
bisected it and adding class variables or adding some code made it g
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:52
---
Subject: Bug 45353
Author: ebotcazou
Date: Tue Aug 31 11:52:01 2010
New Revision: 163670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163670
Log:
Backport from mainline
2010-08-20 Jakub
--- Comment #1 from yotambarnoy at gmail dot com 2010-08-31 11:52 ---
Created an attachment (id=21602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21602&action=view)
Logic.ii, where gcc makes the mistake
LogicUp() is the critical function
--
http://gcc.gnu.org/bugzilla/show
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:53
---
On the 4.5 branch as well.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from yotambarnoy at gmail dot com 2010-08-31 11:53 ---
Created an attachment (id=21603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21603&action=view)
header.h, used by logic.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-31 11:55 ---
Created an attachment (id=21604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21604&action=view)
gcc46-pr45461.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-08-31 12:17 ---
Ok, patch sent to gcc's ML. This issue can lead to troubles on Windows OSes
Vista or newer. But this bug isn't just x86_64-*-mingw32 one. It affects (if
more recent import-libraries are used) even 32-bit mingw and cyg
Consider the following code:
program test
implicit none
character(40) line
line = 'Hello World!'
write (line, '(i3, 2x, a)') 7, trim(line)
print *, line
end program
With the gfortran compiler (v4.5.1) the output is:
77lo World!
I would expect the output to be
7 Hello World!
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-08-31
12:57 ---
Testresults for PR36502v2.patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that
the only additional failures triggered by this patch are listed in comment 11.
--
http:/
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-31 13:28 ---
Did you see the responses to your post in c.l.f?
It seems that your program is non-conforming. I
leave the PR open until either I or someone else
has time to verify the conformity of the program.
--
http://gcc.gn
--- Comment #2 from pluto at agmk dot net 2010-08-31 13:45 ---
no, it still doesn't work with 4.5.2 on linux hosted cross compiler.
gcc finds libgcc_s pretty well during linking:
%
/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-gcc
t.c -shared-libgcc -Wl,--
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-31 13:48
---
(In reply to comment #9)
> Created an attachment (id=21599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21599&action=view) [edit]
> rely on PREFERRED_STACK_BOUNDARY_DEFAULT for intel darwin
>
You should k
The following code will warn for line 6 but not for line 5, however, I
_think_the type of "a + a + a" is the same as the type of "a + a".
int main()
{
unsigned char a=0;
unsigned int b =0;
bool test1 =( b < a + a);//no warning, why
bool test2 =( b < a + a + a);//warning
if (wtf1 && wt
--- Comment #1 from brutus at free dot fr 2010-08-31 13:53 ---
There is a small mystake to the snippet, it should read instead:
int main()
{
unsigned char a = 0;
unsigned int b = 0;
bool test1 =( b < a + a);
bool test2 =( b < a + a + a);
if (test1 && test2) return 1;
}
--
--- Comment #14 from hjl dot tools at gmail dot com 2010-08-31 13:54
---
(In reply to comment #12)
> Testresults for PR36502v2.patch at
> http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that
> the only additional failures triggered by this patch are listed in com
--- Comment #5 from Kyle dot D dot Moffett at boeing dot com 2010-08-31
14:03 ---
Created an attachment (id=21605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21605&action=view)
Further stripped testcase with problematic section identified
Ok, I've spent a bit more time fiddlin
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-08-31
14:04 ---
Created an attachment (id=21606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21606&action=view)
Makefile for "test.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-31 14:04 ---
(In reply to comment #4)
> Ok, I could reduce this quite a bit:
>
Good :)
In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
application it still gives a segfault; I think that variant should b
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 ---
(In reply to comment #5)
> In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
> application it still gives a segfault; I think that variant should be checked
> as well.
Note that for MOLD there
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:17 ---
inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
{
struct Unaligned32 { uint32 val; } __attribute__ ((__packed__));
return ((const Unaligned32 *)ptr)->val;
}
and similar look like
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-31 14:18 ---
(In reply to comment #6)
>
> Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now
> MOLD works only with non-polymorphic expressions. Once the PR is fixed,
> polymorphics should work too. Un
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:19 ---
Looks obvious.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|-
--- Comment #2 from david dot sagan at gmail dot com 2010-08-31 14:20
---
(In reply to comment #1)
> Did you see the responses to your post in c.l.f?
> It seems that your program is non-conforming. I
> leave the PR open until either I or someone else
> has time to verify the conformity
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-08-31 14:31 ---
Fixed on trunk and won't be backported to 4.5.x, therefore I close this bug
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from david dot sagan at gmail dot com 2010-08-31 14:32
---
(In reply to comment #2)
> Sorry. When I looked after I had posted the question there was only one
> response and that response said it was a bug so I submitted this bug report.
> Now other people have posted sayi
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 ---
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr and lwl MIPS
instructions without breaking strict aliasing rules...?
Thanks a bunch!
--
yotambarnoy at gmail dot co
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2010-08-31
15:39 ---
Created an attachment (id=21607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21607&action=view)
rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY
--
http://gcc.gnu.org/bugzilla/
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-08-31
15:48 ---
(In reply to comment #14)
> Please try this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html
>
With the patch above and PR36502v3.patch, I still get...
FAIL: gcc.c-torture/execute/bui
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-31 16:13 ---
Subject: Bug 45461
Author: jakub
Date: Tue Aug 31 16:13:14 2010
New Revision: 163678
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163678
Log:
PR middle-end/45461
* builtins.c (dummy_object):
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-08-31
16:30 ---
With http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html and the patch in
comment 15, I am also still failing at -m32 on x86_64-apple-darwin10...
FAIL: gcc.dg/nest.c execution test
FAIL: gcc.dg/tortu
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-08-31
16:36 ---
Created an attachment (id=21608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21608&action=view)
assembly from failing gcc.dg/nest.c execution test at -m32 on
x86_64-apple-darwin10
Generated with..
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-31 16:40 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Sorry. When I looked after I had posted the question there was only one
> > response and that response said it was a bug so I submitted this bug report.
> > Now o
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2010-08-31
16:41 ---
(In reply to comment #18)
In gdb, the failing nest.exe exection shows...
Starting program: /Users/howarth/stack_align_bug2/nest.exe
Reading symbols for shared libraries ++. done
Program received signa
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-08-31
16:42 ---
Created an attachment (id=21609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21609&action=view)
assembly from failing gcc.dg/torture/stackalign/alloca-4.c -O1 execution test
at -m32 on x86_64-app
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-08-31
16:46 ---
(In reply to comment #20)
Created alloca-4.s with...
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-10
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-31 16:47 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-31 16:49 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Sorry. When I looked after I had posted the question there was only one
> > > response and that response said it was a bug so I sub
This is a somewhat curious issue as one needs fairly recent gcc (>= 4.5) _and_
gdb ( > 2010-07-29 ) to reproduce.
- snip -
#!/bin/sh
# To reproduce:
# - use g++ 4.5 or 4.6 (but not 4.4)
# - use gdb from CVS from 2010-07-29 or newer
echo "
template
void x(_Fo
--- Comment #1 from andre dot poenitz at nokia dot com 2010-08-31 17:08
---
This is also tracked on gdb's bugzilla as
http://sourceware.org/bugzilla/show_bug.cgi?id=11961
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
--- Comment #2 from andre dot poenitz at nokia dot com 2010-08-31 17:08
---
This is now also tracked on the gcc bugzilla as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
--- Comment #26 from andrew at atrens dot ca 2010-08-31 17:14 ---
(In reply to comment #25)
> try -march=i686 it should be the best
>
What about the fact that Geode LX does not have a NOPL instruction, while i686
does. Couldn't that result in binaries that crash?
--Andrew
--
http
--- Comment #28 from jason at gcc dot gnu dot org 2010-08-31 17:26 ---
(In reply to comment #18)
> The optimization question in Comment #11 was answered incorrectly.
>
> The C++ standard in fact requires that Y be initialized before the constructor
> is run; see [basic.start.init].
I d
The program will crash if compile with version 4.4.3 or 4.3.2 but works with
4.1.2.
Main program is written in C. (see the following)
/*
* C file passdouble.c
* To compile the program, using the following command.
*gcc passdouble.c requestdouble.o -lgfortran
*/
#include
extern char* reque
--- Comment #13 from paolo at gcc dot gnu dot org 2010-08-31 17:40 ---
Subject: Bug 44480
Author: paolo
Date: Tue Aug 31 17:39:51 2010
New Revision: 163686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163686
Log:
2010-08-31 Paolo Carlini
PR libstdc++/44480
--- Comment #29 from mmitchel at gcc dot gnu dot org 2010-08-31 17:41
---
Jason --
I can't argue with that as a literal reading of the standard, but is there any
reason why the standard doesn't allow const float variables in (not necessarily
integral) constant expressions just as we al
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-31 17:41
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #26 from davidxl at gcc dot gnu dot org 2010-08-31 17:45
---
Good observation re. the number of IVs in the final set. This usually points to
some problem/bug in the cost function. I briefly looked at this case -- it
indeed exposes two more bugs in the cost model:
1) the com
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 17:45 ---
I think the return value for character(16) returns are passed via the first
argument. So I think this is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
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.
include
void requestdouble_(double*, double*, char *, int *len);
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
Closing as INVALID.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #4 from Lulin dot Song at gmail dot com 2010-08-31 18:02
---
(In reply to comment #1)
> I think the return value for character(16) returns are passed via the first
> argument. So I think this is invalid.
>
If the return value of function 'requestdouble' is changed to be i
--- Comment #27 from rootkit85 at yahoo dot it 2010-08-31 18:02 ---
you could try but i'm not sure that NOPL is mandatory for the i686 arch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
--- Comment #5 from Lulin dot Song at gmail dot com 2010-08-31 18:06
---
(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.
>
> include
>
> void requestd
--- Comment #4 from tromey at gcc dot gnu dot org 2010-08-31 18:33 ---
Created an attachment (id=21610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21610&action=view)
a simple test case
I'm attaching "temargs.cc", a simple test case from the gdb test suite.
I compiled this with
--- Comment #3 from bero at arklinux dot org 2010-08-31 18:48 ---
Created an attachment (id=21611)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21611&action=view)
(fairly stupid) Workaround
Attaching workaround for people coming across this bug report when googling the
error mess
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2010-08-31 18:57
---
Subject: Bug 38282
Author: fxcoudert
Date: Tue Aug 31 18:56:46 2010
New Revision: 163691
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163691
Log:
PR fortran/38282
* f95-lang.c (gfc_ini
--- Comment #4 from zsojka at seznam dot cz 2010-08-31 19:07 ---
Created an attachment (id=21612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21612&action=view)
different testcase, probably better
This one needs only -O2 to reproduce:
$ valgrind -q --trace-children=yes gcc -O2
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-31 19:09 ---
(In reply to comment #5)
> Thanks. I do know how to work around it with subroutine which I already did in
> my program. But it doesn't explain why 4.1.2 version allows return character
> string from function. Our prog
On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com" > wrote:
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
15:24 ---
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr
and lwl MIPS
instructions without breaki
--- Comment #5 from pinskia at gmail dot com 2010-08-31 19:09 ---
Subject: Re: Bad optimization in -O3 sometimes
On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com"
wrote:
>
>
> --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
> 15:24 ---
> Good job pi
--- Comment #8 from sfilippone at uniroma2 dot it 2010-08-31 19:20 ---
(In reply to comment #7)
> (In reply to comment #6)
>
> Fine. Waiting for it
>
Consider the following variation: upon exit from DOIT, the ACSR variable should
be deallocated (since it was MOVE_ALLOCed to atx%a)
--- Comment #9 from sfilippone at uniroma2 dot it 2010-08-31 19:21 ---
Created an attachment (id=21613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-31 19:48 ---
Created an attachment (id=21614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21614&action=view)
gcc46-pr45250.patch
The problem is that the PA backend has quite lame setup, where
FRAME_POINTER_REGNUM is the sa
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-08-31
19:50 ---
Created an attachment (id=21615)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21615&action=view)
assembly from stock build of gcc.dg/nest.c execution test at -m32 on
x86_64-apple-darwin10
--
ht
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-08-31
19:55 ---
Created an attachment (id=21616)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21616&action=view)
assembly from stock build of gcc.dg/torture/stackalign/alloca-4.c -O1
execution test at -m32 on x86
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-08-31
19:57 ---
Created an attachment (id=21617)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21617&action=view)
diff between nest.s.stock and nest.s show alignment changes in failing test
case
--
http://gcc.g
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-08-31
19:59 ---
Created an attachment (id=21618)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21618&action=view)
diff between alloca-4.s.stock and alloca-4.s show alignment changes in failing
test case
--
http
Hello,
I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o
gcctest':
<<<
#include
static int array[32];
#if 0 // If '#if 1' is used, GCC warns correctly about the use of uninitialized
variable 'i' below.
void foo(void);
void foo(void)
#else
static void foo
--- Comment #1 from jellegeerts at gmail dot com 2010-08-31 20:02 ---
Created an attachment (id=21619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21619&action=view)
output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest'
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:03 ---
Created an attachment (id=21620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21620&action=view)
output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest'
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:03 ---
Created an attachment (id=21621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21621&action=view)
the `.i' file that GCC created
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
--- Comment #4 from jellegeerts at gmail dot com 2010-08-31 20:04 ---
Created an attachment (id=21622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21622&action=view)
`.i' file that GCC created
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
--- Comment #3 from tromey at gcc dot gnu dot org 2010-08-31 20:12 ---
This was purely a gdb bug.
It only showed up with a newish gcc because older ones don't emit
DW_TAG_template_*.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- 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 uninitial
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:24 ---
Reopening bug.
--
jellegeerts at gmail dot com changed:
What|Removed |Added
Status|RESOL
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 ---
#include
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 gets put
--- 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=21607&action=view) [edit]
> rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY
>
This
--- 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
static int array[32];
#if 0 // If '#if 1' is used, GCC wa
--- 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
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. Th
1 - 100 of 154 matches
Mail list logo
