Yesterday, I spent an hour looking for the C99 and C++0x status
pages in http://gcc.gnu.org/,
http://gcc.gnu.org/c99status.html
http://gcc.gnu.org/projects/cxx0x.html
Apparently, the shortest path to the latter is
Releases
- GCC 4.5.1
- GCC 4.5.1 Jul 31, 2010 (changes)
-
On 08/30/2010 03:50 PM, Vincent Lefevre wrote:
On 2010-08-30 14:46:57 +0200, Michael Matz wrote:
int x = x;
is the way GCC offers this idiom since about forever, no need for an
attribute. Downthread I see that people worry about this generating an
actual (uninitialized) access to x. They
Andre Majorel wrote:
Those are among the most useful pages of the site, it makes no
sense to bury them 4+ levels deep.
Google is your friend: when asked for g++ c++0x it returns
the correct page as the first result. I always use it that way,
because website messiness appears to be a de facto
I will be looking at the patch Rahul posted and will try to see if I
can improve on it.
See attached patch (again) that Paulo is referring to. Sending to GCC
failed due to email client issues.
I have another patch for http://gcc.gnu.org/ml/gcc/2010-08/msg00413.html
Which I will send out
On 8/31/2010 1:19 AM, Andrew Haley wrote:
On 08/30/2010 03:50 PM, Vincent Lefevre wrote:
On 2010-08-30 14:46:57 +0200, Michael Matz wrote:
int x = x;
is the way GCC offers this idiom since about forever, no need for an
attribute. Downthread I see that people worry about this generating an
We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27,
2010 (the closing day of the GCC Summit). Major features should be
checked in prior to this point. Please let us know if you have a major
feature that you think you will not be able to get checked in prior to
October 27th.
On 08/30/2010 08:36 PM, Adam Jiang wrote:
On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote:
On 08/30/2010 09:46 AM, Richard Henderson wrote:
On 08/30/2010 03:45 AM, Adam Jiang wrote:
When I read the source in Linux kerne, it was said that stack canary for
implementing stack
Snapshot gcc-4.4-20100831 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100831/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
In fact we might want to move switch optimization up to the tree level
(just because it's way easier to deal with there). Thus, lower switch
to a mixture of binary tree jump-tables (possibly using perfect
hashing).
Doing the optimisation at the tree-level was exactly my initial idea.
H.J.
gcc 4.6 Atom 2010-Q3.xlsx
Description: gcc 4.6 Atom 2010-Q3.xlsx
Lu, Hongjiu would like to recall the message, Atom 2010-Q3 SPEC CPU 2K
results.
--- 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:
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE: in |[4.5/4.6 Regression] ICE: in
--
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
--- 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=gccview=revrev=163669
Log:
2010-08-31 Richard Guenther rguent...@suse.de
PR
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=21600action=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=21601action=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
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
--- 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=gccview=revrev=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=21602action=view)
Logic.ii, where gcc makes the mistake
LogicUp() is the critical function
--
--- 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=21603action=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=21604action=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
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.
--
--- 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.
--
--- 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
--- 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=21599action=view) [edit]
rely on PREFERRED_STACK_BOUNDARY_DEFAULT for intel darwin
You should keep
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 wtf2)
--- 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
--- 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=21605action=view)
Further stripped testcase with problematic section identified
Ok, I've spent a bit more time fiddling
--- 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=21606action=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 be
--- 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 is
--- 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. Until
--- 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
--- 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 of
--- 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 saying
--- 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
--- 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=21607action=view)
rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY
--
--- 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:
--- 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=gccview=revrev=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:
--- 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=21608action=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 other
--- 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
--- 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=21609action=view)
assembly from failing gcc.dg/torture/stackalign/alloca-4.c -O1 execution test
at -m32 on
--- 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/
--- 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 submitted
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
templatetypename
--- 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
--
--- 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
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 stdio.h
extern
--- 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=gccview=revrev=163686
Log:
2010-08-31 Paolo Carlini paolo.carl...@oracle.com
PR
--- 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
--- 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
--- 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
--- 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 stdio.h
void requestdouble_(double*, double*, char *,
--- 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
--- 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
--- 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 stdio.h
void
--- 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=21610action=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=21611action=view)
(fairly stupid) Workaround
Attaching workaround for people coming across this bug report when googling the
error
--- 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=gccview=revrev=163691
Log:
PR fortran/38282
* f95-lang.c
--- 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=21612action=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
On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org
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
--- 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
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
15:24
--- 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=21613action=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=21614action=view)
gcc46-pr45250.patch
The problem is that the PA backend has quite lame setup, where
FRAME_POINTER_REGNUM is the
--- 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=21615action=view)
assembly from stock build of gcc.dg/nest.c execution test at -m32 on
x86_64-apple-darwin10
--
--- 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=21616action=view)
assembly from stock build of gcc.dg/torture/stackalign/alloca-4.c -O1
execution test at -m32 on
--- 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=21617action=view)
diff between nest.s.stock and nest.s show alignment changes in failing test
case
--
--- 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=21618action=view)
diff between alloca-4.s.stock and alloca-4.s show alignment changes in failing
test case
--
Hello,
I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o
gcctest':
#include stdio.h
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(void)
--- 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=21619action=view)
output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest'
--
--- 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=21620action=view)
output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest'
--
--- 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=21621action=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=21622action=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
1 - 100 of 162 matches
Mail list logo
