I am a PhD student who has been working with CUDA for the GPU and also
gcc for Cell BE for about a year now. (By work I mean developing
applications). I am looking to bring GCC closer to being able to
support OpenCL as a Google Summer of Code.
This is very interesting and I'm willing to help
Ralf Corsepius ralf.corsep...@rtems.org writes:
Pardon, there seems to be a misunderstanding. I only was surprised to see
FreeBSD shipping much newer versions of packages than most Linux distros
(even those who claim to be (b)leading edge).
If you want to have the bleading edge you need to
On Mon, 30 Mar 2009, Paolo Bonzini wrote:
2) half-precision floats;
I expect Sandra will be merging half-precision support for ARM to trunk
fairly soon; see her announcement
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01062.html. This includes
generic support for the IEEE half-precision
Joseph S. Myers wrote:
On Mon, 30 Mar 2009, Paolo Bonzini wrote:
2) half-precision floats;
I expect Sandra will be merging half-precision support for ARM to trunk
fairly soon; see her announcement
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01062.html. This includes
generic support
Jakub Jelinek wrote:
On Sun, Mar 29, 2009 at 01:00:50PM +0200, FX wrote:
This mail is a request for some help from our local build machinery
experts... We have a patch under testing for libgfortran to add
runtime memleaks checking, and it uses libiberty's hash tables. So, we
now link
+1. If libgfortran includes a custom allocator of any sort (does it?)
instead of using malloc/free, it should use valgrind hooks like
those we
already have in GCC.
libgfortran uses malloc/free.
Regarding valgrind, it's not supported on all GCC targets, so it's not
a valid alternative to
FX wrote:
+1. If libgfortran includes a custom allocator of any sort (does it?)
instead of using malloc/free, it should use valgrind hooks like those we
already have in GCC.
libgfortran uses malloc/free.
Regarding valgrind, it's not supported on all GCC targets, so it's not a
valid
For Windows, I found
http://www.codeproject.com/KB/applications/visualleakdetector.aspx which
is free (LGPL); I don't know how good it is and it may be hard to
compile it to GCC, but doing that would be a better service than adding
a leak detector to libgfortran (Purify is proprietary and
On Mon, Mar 30, 2009 at 01:09:56AM -0700, Paolo Bonzini wrote:
I am a PhD student who has been working with CUDA for the GPU and also
gcc for Cell BE for about a year now. (By work I mean developing
applications). I am looking to bring GCC closer to being able to
support OpenCL as a
Hi All,
Thanks for the feedback. As far as the NVIDIA ISA details, I have the
pdf that describes it. In the CUDA toolkit, available on NVIDIA's
website there is a pdf named ptx_isa_1.3.pdf under the doc directory.
(Get it from here http://www.nvidia.com/object/cuda_get.html).
So we can do
On Mon, Mar 30, 2009 at 10:10:24AM -0700, phil++ wrote:
Hi All,
Thanks for the feedback. As far as the NVIDIA ISA details, I have the
pdf that describes it. In the CUDA toolkit, available on NVIDIA's
website there is a pdf named ptx_isa_1.3.pdf under the doc directory.
(Get it from here
So we can do Intel, ATI and NVIDIA GPU backends. NVIDIA already has
an implementation of OpenCL working.
http://www.nvidia.com/object/cuda_opencl.html. Would there be any
sharing involved with them??
If you mean between backends, 1) do not underestimate the time needed to
write a new GCC
Joe Buck,
You have to choose an operating system and then a table appears below
it to download the CUDA toolkit.
Phil
On Mon, Mar 30, 2009 at 1:32 PM, Joe Buck joe.b...@synopsys.com wrote:
On Mon, Mar 30, 2009 at 10:10:24AM -0700, phil++ wrote:
Hi All,
Thanks for the feedback. As far as
I have two questions regarding the use on __restrict__ qualifiers for function
arguments in C++:
1) How does it interact with volatile?
Example, given:
void foo(volatile int* __restrict__ p1,
volatile int* __restrict__ p2)
{
*p1 = 3;
if (*p1 == 5)
quick == quick qu...@sparq.org writes:
quick I have two questions regarding the use on __restrict__
quick qualifiers for function arguments in C++:
quick 1) How does it interact with volatile?
quick Example, given:
quick void foo(volatile int* __restrict__ p1, volatile int*
quick
Dobes bdo...@udel.edu writes:
See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the
back-ends.
Or, better, look for uses of lookup_attribute.
OK, I've now got it working for globals and static locals by tagging the rtl
in encode_section_info and checking for that tag later.
Ian Lance Taylor-3 wrote:
Dobes bdo...@udel.edu writes:
See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the
back-ends.
Or, better, look for uses of lookup_attribute.
OK, I've now got it working for globals and static locals by tagging the
rtl
in encode_section_info
Paolo Bonzini writes:
Regarding the NVIDIA GPU backend, I think NVIDIA is not yet distributing
details about the instruction set unlike ATI, is it? In this case, I
think ATI would be a better match.
I think a GPU backend would be well beyond the scope of a Summer of
Code project. GPUs don't
Dobes bdo...@udel.edu writes:
Could you clarify a little about how/where to use lookup_attribute?
Use it wherever it is you need to know whether a symbol has your
attribute (I don't know when you need the information). In RTL you can
normally find the VAR_DECL using MEM_EXPR or REG_EXPR.
Ian
Joe Buck writes:
I'm having trouble finding that document, I don't see a link to it
on that page. Maybe I'm missing something obvious?
Sticking nvidia ptx into Google turned up this document:
http://www.nvidia.com/object/io_1195170102263.html
It's an intermediate language, so isn't
Hello,
I'm working on a patch which makes FDO profile data more robust to
source changes. Before I sent the patch to the list for review, I was
wondering how to write a test for this situation. In particular, what
I would like to have is two source files which are similar but not the
same. The
Paolo,
Thanks for the feedback, I am not very experienced in compilers so it
is hard to judge how long a task will take...
By sharing I meant sharing of code between NVIDIA and GCC. It
probably won't happen I guess.
Here is my proposal for an OpenCL runtime with a target runtime as
well. If
On Mon, Mar 30, 2009 at 01:36:14PM -0700, Ross Ridge wrote:
Joe Buck writes:
I'm having trouble finding that document, I don't see a link to it
on that page. Maybe I'm missing something obvious?
Sticking nvidia ptx into Google turned up this document:
On Mon, 2009-03-30 at 13:53 -0700, Neil Vachharajani wrote:
Hello,
I'm working on a patch which makes FDO profile data more robust to
source changes. Before I sent the patch to the list for review, I was
wondering how to write a test for this situation. In particular, what
I would like to
On Mon, 30 Mar 2009, Ross Ridge wrote:
2) half-precision floats;
Do you mean just conversion only support, like Sandra Loosemore's
proposed ARM patch, or full arithmetic support like any other scalar or
vector type?
Arithmetic via converting to float, doing arithmetic on that and
On Mon, Mar 30, 2009 at 2:50 PM, Janis Johnson janis...@us.ibm.com wrote:
On Mon, 2009-03-30 at 13:53 -0700, Neil Vachharajani wrote:
Hello,
I'm working on a patch which makes FDO profile data more robust to
source changes. Before I sent the patch to the list for review, I was
wondering how
On Mar 21, 2009, Andrew MacLeod amacl...@redhat.com wrote:
I was planning to send this note next week, but I guess I should know
better than to put something on the wiki and think it won't be
noticed, even if it is in a crusty dark corner :-)
:-)
I see on #gcc that my debuglocus document
Hi Ho!
On Fri, 2009-03-27 at 13:49 +0100, Paolo Bonzini wrote:
Eus wrote:
Hi Ho!
On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping
Just to clarify is gcc.dg/tree-prof/wcoverage-mismatch.c an example of
what you are talking about? If so, I really like this is approach.
Thanks for the feedback!
Neil
On Mon, Mar 30, 2009 at 4:41 PM, Andrew Pinski pins...@gmail.com wrote:
On Mon, Mar 30, 2009 at 2:50 PM, Janis Johnson
Thank you for your advice. Compared RICE (my processor name) RTL and
MIPS RTL, I found the problem. Because of the subreg operations which
I missed to add support in my RTL. I noticed the mips rtl code which
will convert the QImode and HI mode to SImode operations. Like the
following:
(insn 28
daniel tian daniel.xnt...@gmail.com writes:
But the question is how I make the gcc know to extend every smaller
mode to SImode. Now I check the MIPS port, maybe I can find some clue.
Maybe PROMOTE_MODE.
Ian
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-30 08:26 ---
Btw, this should be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-30 08:37 ---
A patch has been submitted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01604.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39583
--- Comment #3 from dominiq at lps dot ens dot fr 2009-03-30 08:36 ---
A patch has been submitted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01631.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39325
--- Comment #2 from nemokingdom at gmail dot com 2009-03-30 11:30 ---
I test with bootstrap enabled and success.
Here is the patch:
Index: sese.h
===
--- sese.h (revision 145190)
+++ sese.h (working copy)
@@
kernel/fork.c: In function `copy_process':
kernel/fork.c:1405: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
linux kernel version:
The following program works with NAG f95, g95, sunf95, ifort but fails with a
Fortran runtime error: End of file
in gfortran. I think the program is valid.
-
implicit none
character(len=5) :: str
integer :: a
str = ''
a = 5
read(str,'(5x,i1)') a
print *, a
if(a
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-03-30 12:59 ---
Subject: Bug 39583
Author: jsm28
Date: Mon Mar 30 12:59:27 2009
New Revision: 145290
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145290
Log:
2009-03-30 Dominique d'Humieres domi...@lps.ens.fr
PR
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-03-30 13:14 ---
Fixed by that commit.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
# gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.3/configure --prefix=/tmp/gcc433
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.3 (GCC)
with the following, self-contained file buc.c
#define lit_from_int(in) ((in0)?(((-in)1)|1):(in1))
void
--- Comment #4 from dominiq at lps dot ens dot fr 2009-03-30 13:32 ---
Note that there may be a similar issue for *x86_64*-*-darwin* with -m32, but
I cannot test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39325
--- Comment #1 from olivier dot roussel at cril dot univ-artois dot fr
2009-03-30 13:48 ---
Created an attachment (id=17558)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17558action=view)
test source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39588
--- Comment #22 from jakub at gcc dot gnu dot org 2009-03-30 13:51 ---
What exact regression was fixed by the
http://gcc.gnu.org/viewcvs?root=gccview=revrev=145102
commit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-30 14:24 ---
Confirmed. -ftree-vectorize is the problem or maybe triggers a target problem.
#1 0x00605517 in trunc_int_for_mode (c=0, mode=V4SImode)
at /space/rguenther/src/svn/trunk/gcc/explow.c:56
56
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-30 14:29 ---
Subject: Bug 38781
Author: hjl
Date: Mon Mar 30 14:29:10 2009
New Revision: 145292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145292
Log:
2008-03-30 H.J. Lu hongjiu...@intel.com
PR target/38781
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-30 14:33 ---
Fixed for 4.5.0. No plan to back port.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-30 14:35 ---
Subject: Bug 39563
Author: jakub
Date: Mon Mar 30 14:35:03 2009
New Revision: 145293
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145293
Log:
PR debug/39563
* c-decl.c (struct c_binding): Add
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39492
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P2
--- Comment #3 from jmcdonald at fairfield dot com 2009-03-30 14:44 ---
Created an attachment (id=17559)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17559action=view)
A more simple test case which recreates the memor correction bug (1 file)
I worked with the sources a bit more,
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-30 14:56 ---
We want to simplify
(ashift:V4SI (neg:V4SI (reg:V4SI 87))
(const_int 1 [0x1]))
to
(neg:V4SI (ashift:V4Si (reg:V4SI 87)
(const_int 1 [0x1]))
but the code obviously doesn't expect vector modes. For the
--- Comment #4 from jmcdonald at fairfield dot com 2009-03-30 14:59 ---
Created an attachment (id=17560)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17560action=view)
The GCC preprocessed files to go with the simple, one-source-file test case.
And here are the gcc preprocessed
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-30 15:01 ---
Subject: Bug 39558
Author: jakub
Date: Mon Mar 30 15:00:52 2009
New Revision: 145297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145297
Log:
PR target/39558
* macro.c (cpp_get_token): If
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-30 15:06 ---
Subject: Bug 39558
Author: jakub
Date: Mon Mar 30 15:06:14 2009
New Revision: 145298
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145298
Log:
PR target/39558
* macro.c (cpp_get_token): If
--- Comment #3 from tromey at gcc dot gnu dot org 2009-03-30 15:15 ---
Not a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-30 15:23 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-30 15:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from tromey at gcc dot gnu dot org 2009-03-30 15:26 ---
Subject: Bug 39512
Author: tromey
Date: Mon Mar 30 15:25:42 2009
New Revision: 145300
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145300
Log:
PR preprocessor/39512:
* line-map.c
--- Comment #3 from tromey at gcc dot gnu dot org 2009-03-30 15:26 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jsm28 at gcc dot gnu dot org 2009-03-30 15:28 ---
fix-header has been removed for 4.5, so all bugs relating to it are gone.
Most targets no longer use it, a few that used it were removed.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from jsm28 at gcc dot gnu dot org 2009-03-30 15:37 ---
Closing 4.2 branch. Original bug was fixed for 4.2.0, rejects-valid
for 4.3.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from jsm28 at gcc dot gnu dot org 2009-03-30 15:39 ---
Closing 4.2 branch, reported as working with 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jsm28 at gcc dot gnu dot org 2009-03-30 15:41 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-03-30 15:42 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jsm28 at gcc dot gnu dot org 2009-03-30 15:43 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jsm28 at gcc dot gnu dot org 2009-03-30 15:43 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from jsm28 at gcc dot gnu dot org 2009-03-30 15:44 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jsm28 at gcc dot gnu dot org 2009-03-30 15:45 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-03-30 15:46 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jsm28 at gcc dot gnu dot org 2009-03-30 15:47 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-03-30 15:26 ---
protoize has been removed for GCC 4.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from jsm28 at gcc dot gnu dot org 2009-03-30 15:48 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jsm28 at gcc dot gnu dot org 2009-03-30 15:49 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from jsm28 at gcc dot gnu dot org 2009-03-30 15:50 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jsm28 at gcc dot gnu dot org 2009-03-30 15:51 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-03-30 15:52 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jsm28 at gcc dot gnu dot org 2009-03-30 15:54 ---
Closing 4.2 branch. The patch actually went on trunk before 4.2 branched.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from laurent at guerby dot net 2009-03-30 15:58 ---
Kaz, do you know if this problem fixed in 4.2/4.3/4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24836
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-30 15:58
---
Your code triggers undefined behaviour here:
const char* OutBuf = reinterpret_castconst char*(OutStream.str().c_str());
because str() returns a temporary string, which then dies, leaving OutBuf
pointing to
--- Comment #3 from sje at gcc dot gnu dot org 2009-03-30 16:44 ---
Subject: Bug 38237
Author: sje
Date: Mon Mar 30 16:43:40 2009
New Revision: 145303
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145303
Log:
PR middle-end/38237
* tree.h (tree_find_value): New
--- Comment #4 from sje at cup dot hp dot com 2009-03-30 16:46 ---
Closing out as fixed in 4.5. It is probably not worth backporting to 4.4 since
it doesn't cause any failures that we know of.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #11 from aran at 100acres dot us 2009-03-30 16:51 ---
(In reply to comment #9)
My mistake, I printed the operands to mpz_pow_ui and got
gfc_arith_power: op1 = 2
gfc_arith_power: power = 2147483647
When I call mpz_pow_ui from c with these arguments, I get
GNU MP: Cannot
--- Comment #14 from jsm28 at gcc dot gnu dot org 2009-03-30 16:57 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jsm28 at gcc dot gnu dot org 2009-03-30 16:58 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2009-03-30 16:59 ---
Closing this out since it is now fixed for 4.5.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #9 from jsm28 at gcc dot gnu dot org 2009-03-30 17:00 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-03-30 17:00 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-03-30 17:01 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-30 17:01
---
This is probably the same as target/37436. However, that fix has not been
back-ported to the 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36415
--- Comment #15 from jsm28 at gcc dot gnu dot org 2009-03-30 17:02 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-03-30 17:03 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-03-30 17:03 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jsm28 at gcc dot gnu dot org 2009-03-30 17:04 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Compiling this with -Wmissing-field-initializers evokes a warning:
struct foo { int a; int b; };
struct foo f = { 1 };
but with designated initializers it does not:
struct foo { int a; int b; };
struct foo f = { .a = 1 };
That -Wmissing-field-initializers works this way is even
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-03-30 17:05 ---
Closing 4.2 branch, fixed in 4.3.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-03-30 17:11 ---
Assigning to self.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2009-03-30 17:42 ---
Subject: Bug 35652
Author: jakub
Date: Mon Mar 30 17:42:27 2009
New Revision: 145308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145308
Log:
Revert PR c++/35652
Removed:
--- Comment #4 from roger dot ferrer at bsc dot es 2009-03-30 18:04 ---
Thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39512
--- Comment #1 from ramana at gcc dot gnu dot org 2009-03-30 18:10 ---
Confirmed. The compiler could generate a
mov sp, r3 instead and the code would be right.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 256 matches
Mail list logo
