The patch looks good. Please install.
I also have installed a similar patch in htdocs/gcc-4.4/changes.html
--- Comment #2 from sebpop at gmail dot com 2008-10-02 06:18 ---
Subject: Re: typo in the example for -floop-strip-mine
The patch looks good. Please install.
I also have installed a similar patch in htdocs/gcc-4.4/changes.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690
The following test module creates two derived type, with the second extending
the first. Type-bound procedures for initialization are defined by both.
However when the init routine for the extended derived type attempts to call
the init routine in the parent type, via the parent component name,
--- Comment #1 from domob at gcc dot gnu dot org 2008-10-02 07:22 ---
(In reply to comment #0)
subroutine x_init (this, text, value)
type(x_t) :: this
character(*) :: text
integer :: value
call base_t%init (text)
! or...
call base_init (base_t, text)
I
--- Comment #9 from dannysmith at gcc dot gnu dot org 2008-10-02 08:39
---
Subject: Bug 37528
Author: dannysmith
Date: Thu Oct 2 08:37:36 2008
New Revision: 140830
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140830
Log:
PR target/37528
* config/i386/mingw32.h
--- Comment #10 from dannysmith at users dot sourceforge dot net
2008-10-02 08:47 ---
Fixed on mingw32 at revision 140803.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
--- Comment #14 from jakub at gcc dot gnu dot org 2008-10-02 08:51 ---
This is a simple buffer overflow in lambda-code.c.
It is easily reproduceable everywhere with the #c12 testcase with just
-O3 -ftree-loop-linear -funroll-loops
if you add an assert:
--- lambda-code.c.jj 2008-09-05
I just tried to compile the Suse Linux package libbtctl-0.10.0
with the new gcc version 4.4, snapshot dated 20080926.
gcc said
obexsdp.c: In function 'register_sdp':
obexsdp.c:128: internal compiler error: in vectorizable_store, at
tree-vect-transform.c:5391
Please submit a full bug report,
with
--- Comment #1 from dcb314 at hotmail dot com 2008-10-02 09:04 ---
Created an attachment (id=16450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16450action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37713
--- Comment #15 from jakub at gcc dot gnu dot org 2008-10-02 09:05 ---
Given that the cy vector is supposed to have 3 parts, the first for ivs, the
second for (optional) parameters and the last entry for constant column, and
av_for_af_base adds stuff to constant column and to the
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-02 09:11 ---
*** This bug has been marked as a duplicate of 37285 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-02 09:11 ---
*** Bug 37666 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-02 09:12 ---
*** This bug has been marked as a duplicate of 37285 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2008-10-02 09:12 ---
*** Bug 35874 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
I've been experiencing some (for me) rather unexpected behavior with some C++
code. The following is a very reduced test case:
class A
{ private: void *one;
} __attribute__((aligned(16)));
class C {};
class L { public: class M : A { C _c; }; M m; };
L x;
It's about the size of L::M. I.e. if
I compiled the code below with:
/opt/local/bin/gcc-mp-4.3 -Wall -O3 -fno-inline main.i
There were no warnings or errors from the compiler. The
result of executing a.out was:
z.imag is 0.00; expected -0.00
If the -O3 option is dropped, or -fno-builtin is added, then the output is as
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 11:06 ---
We seem to accumulate an awful huge stack of BLOCKs during inlining ... are
BLOCKs shared? Maybe we can avoid copying equivalent ones.
This testcase is bad, as in the end we will optimize it all away to a constant
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-02 11:08 ---
This basically boils down to moving optimizing case labels earlier (we do
so after going out-of-ssa).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-02 11:19 ---
Confirmed. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sent from my iPhone
On Oct 2, 2008, at 2:09 AM, adam at os dot inf dot tu-dresden dot de
[EMAIL PROTECTED] wrote:
I've been experiencing some (for me) rather unexpected behavior with
some C++
code. The following is a very reduced test case:
This comes down to non pod vs pod and tail
--- Comment #1 from pinskia at gmail dot com 2008-10-02 11:24 ---
Subject: Re: New: Different class sizes with public/private and alignments
Sent from my iPhone
On Oct 2, 2008, at 2:09 AM, adam at os dot inf dot tu-dresden dot de
[EMAIL PROTECTED] wrote:
I've been experiencing
--- Comment #6 from amonakov at gcc dot gnu dot org 2008-10-02 11:27
---
This patch also fixes miscompilation of vla1.f90 test on ia64 on sel-sched
branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37447
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-02 11:42 ---
Works on Linux where it replaces it with a call to sincos. Also works with
the Linux glibc if explicitly calling cexp like
static my_complex
c_rect(double phi)
{
my_complex z;
z.imag = __imag cexp (I * phi);
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-02 12:11 ---
I'm completely lost with your example. You are talking about parent component
name, but you have:
type x_t
which has no parent component.
Id had one if you used type, extends(base_t) :: x_t. Then you could use:
--- Comment #7 from dodji at gcc dot gnu dot org 2008-10-02 12:21 ---
@jason: Okay, I have posted the patch that I hope should address your comments.
Sorry to not have posted the patch there earlier. I was not sure about the
approach and didn't want to add too much noise to gcc-patches
I just tried to compile the Suse Linux package libQtWebKit-devel-4.4.0-11
with the new gcc version 4.4, snapshot dated 20080926.
gcc said
puzzlewidget.cpp: In member function 'virtual void
PuzzleWidget::mousePressEvent(Q
MouseEvent*)':
puzzlewidget.cpp:143: internal compiler error: Segmentation
--- Comment #1 from dcb314 at hotmail dot com 2008-10-02 12:31 ---
Created an attachment (id=16451)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16451action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
I just tried to compile the Suse Linux package libQtWebKit-devel-4.4.0-11
with the new gcc version 4.4, snapshot dated 20080926.
gcc said
piecesmodel.cpp: In member function 'virtual QVariant PiecesModel::data(const
QModelIndex, int) const':
piecesmodel.cpp:208: error: definition in block 36
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-02 12:38 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
--- Comment #1 from dcb314 at hotmail dot com 2008-10-02 12:39 ---
Created an attachment (id=16452)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16452action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37717
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-02 12:56 ---
/* When we are not doing full debug info, we however can keep around
only the used variables for cfgexpand's memory packing saving quite
a lot of memory. */
else if (debug_info_level
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-02 13:02 ---
We optimize func_1 to
func_1:
movwg_290(%rip), %ax
movl$0, g_3(%rip)
cwtl
ret
inlining all its callees recursively ...
--
--- Comment #3 from w6ws at earthlink dot net 2008-10-02 13:06 ---
Subject: Re: Parent component name getting confused with
structure constructor
Yes, my example is messed up. My excuse is that it was late and
I was tired. Next time I will verify against NAG first.
Please close
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 13:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-02 13:12 ---
Subject: Bug 37713
Author: rguenth
Date: Thu Oct 2 13:11:12 2008
New Revision: 140832
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140832
Log:
2008-10-02 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2008-10-02 13:52
---
The issue with vector::push_back is fixed in mainline. The issue with std::pair
(per DR 767) is still there, however. Maybe Doug can add something about the
latter...
--
paolo dot carlini at oracle dot com
--- Comment #5 from cvoica at gmail dot com 2008-10-02 13:56 ---
I was trying to compile some code and got this error and thats how I found this
bug.
It seems strange to me that I cannot use a switch within a case branch and the
use the plain std::string.
Testcase:
1. This is working:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 14:10 ---
Confirmed. Reduced testcase:
struct QListData {
struct Data {
int ref;
int alloc, begin, end;
void *array[1];
};
Data *d;
inline void **at(int i) const { return d-array +
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-02 14:19 ---
Indeed.
./cc1plus -quiet -O2 bug21.3.cc -fdump-tree-fre-details
-fdump-tree-pre-details
bug21.3.cc: In function 'void mousePressEvent(int)':
bug21.3.cc:37: error: invalid operand in unary operation
SR.2_12 = (long
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-02 14:26 ---
The difference is mainly that HEAD inlines all func_* calls, while 4.3 keeps
many of them around (I see 30 call func_* insns in 4.3). The 4.4 .text is
about half the size of 4.3 .text (i.e. inliner did much better
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-10-02 14:30
---
You're getting an error because your code is invalid for the reason the error
message states. The reason is that if the value of i is 1, you will end up
in the case 1 part with j uninitialized. You can put the
--- Comment #6 from paolo dot carlini at oracle dot com 2008-10-02 14:32
---
I checked again and the issue certainly doesn't exist anymore in 4_3-branch and
mainline: 9.99989e-321 can be input without underflow to zero and without error
(i.e., cin.good() == 1 after the input).
--
--- Comment #2 from dickinsm at gmail dot com 2008-10-02 14:34 ---
Thanks for the response!
It does appear to be true that cexp doesn't follow
Annex G of C99, on OS X 10.5.5. I agree that this
is undesirable, but I can't see why it should
be considered a bug.
Annex G of C99 is merely
--- Comment #7 from James dot W dot Mckelvey at jpl dot nasa dot gov
2008-10-02 14:36 ---
(In reply to comment #5)
Subject: Re: Stage 2- C compiler cannot create
executables-recent svn
What does stat
/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe report?
$ stat
--- Comment #16 from jakub at gcc dot gnu dot org 2008-10-02 15:03 ---
Wonder whether just am_vector_index_for_loop shouldn't be:
static inline int
am_vector_index_for_loop (struct access_matrix *access_matrix, int loop_num)
{
int depth1 = loop_depth (get_loop (loop_num));
int
--- Comment #10 from pault at gcc dot gnu dot org 2008-10-02 15:20 ---
(In reply to comment #9)
As usual, the DEC manual puts in succinctly:
If MOLD is an array and SIZE is omitted, the result is a rank-one array. Its
size is the smallest that is possible to hold all of SOURCE.
This
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 15:37 ---
Well, Darwin GCC maintainers claim that darwin
/* All new versions of Darwin have C99 functions. */
#define TARGET_C99_FUNCTIONS 1
so we just rely on that. If it is not true then this is either a darwin
bug or
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-02 15:39 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #11 from dominiq at lps dot ens dot fr 2008-10-02 15:48 ---
If the physical representation of the result is smaller than SOURCE, ...
From the xlf manual, I read this for scalar cases, i.e., transfer(x,i) with x
real(4) and i integer(8), or when size is given:
--- Comment #4 from dickinsm at gmail dot com 2008-10-02 15:53 ---
Makes sense. Thanks for the explanation.
I'll go and file a bug with Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37714
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 15:56 ---
Btw, SRA strikes again.
bug22.cc:77593: error: invalid operand in unary operation
SR.1004_28 = (long unsigned int) D.159413_18-array[D.159417_23];
bug22.cc:77593: internal compiler error: verify_stmts failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-02 16:19 ---
Yep, reduced testcase looks exactly the same.
*** This bug has been marked as a duplicate of 37716 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-02 16:19 ---
*** Bug 37717 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
--- Comment #7 from janis at gcc dot gnu dot org 2008-10-02 16:22 ---
The patch from comment #3 passes bootstrap and regtests on powerpc64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37447
int f()
{
return 0;
}
template typename T, typename... U
int f(T t, U... u)
{
return (t ? 1 : 0) * sizeof...(U) + f(u...);
}
int
main()
{
return f(1, 1.0, 2);
}
has 3 mangled names, but 2 of them demangle weirdly (I'd say we should demangle
U10__variadic to something containing ..., not
--- Comment #4 from w6ws at earthlink dot net 2008-10-02 17:18 ---
I am closing this report.
--
w6ws at earthlink dot net changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
= test/test.cpp ==
template typename T
class foo {
void bar() throw(int);
};
template
void fooint::bar() throw(float) {}
= COMMAND ==
g++ -c -o test/test.o test/test.cpp -Wall
= OUTPUT ==
test/test.cpp:7: error: declaration of âvoid
The following code:
#include iostream
#include vector
#include cstddef
struct SomeClass
{
typedef std::vectorint TypeVector;
TypeVector vec;
enum { VectorSize= 10 };
public:
SomeClass();
SomeClass(const SomeClass );
};
SomeClass::SomeClass():vec(VectorSize)
{
--- Comment #1 from ivranos at freemail dot gr 2008-10-02 18:27 ---
Created an attachment (id=16453)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16453action=view)
The produced .ii file
The produced .ii file from code compiled with the options:
g++ -ansi -pedantic-errors -Wall
--- Comment #2 from ivranos at freemail dot gr 2008-10-02 18:33 ---
My mistake. :-)
--
ivranos at freemail dot gr changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-02 18:33 ---
This is the correct behavior really.
The constructor for std::vector which has a size agrument has a default
argument of the type.
I get the same behavior with/without the copy constructor too.
--
pinskia at
--- Comment #5 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
Subject: Bug 37635
Author: steven
Date: Thu Oct 2 18:51:12 2008
New Revision: 140837
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140837
Log:
testsuite
*
The following code gives segmentation fault:
#include iostream
#include ctime
#include vector
#include list
#include cstddef
#include algorithm
class SomeClass
{
public:
typedef std::vectorint TypeVector;
TypeVector vec;
enum { VectorSize= 100 };
public:
--- Comment #1 from ivranos at freemail dot gr 2008-10-02 19:17 ---
Created an attachment (id=16454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16454action=view)
The produced .ii file
This is the produced main.ii file created by
g++ -ansi -pedantic-errors -Wall -save-temps
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-02 19:18
---
Seems easy to fix in dump_function_decl.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from ivranos at freemail dot gr 2008-10-02 19:27 ---
Created an attachment (id=16455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16455action=view)
The produced main.ii file
The produced main.ii file by
g++ -ansi -pedantic-errors -Wall -save-temps main.cc -o
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-10-02 19:31 ---
SRA is doing something funny with VCEs that does not even make sense for SRA to
do really.
It changes:
location.0 ={v} VIEW_CONVERT_EXPRconst struct
QPoint(D.2240_5-array[D.2244_10]);
location ={v} location.0;
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-02 19:33 ---
asm(SLL %[temp], %[c], 16\n\t
MULT %[a], %[c]\n\t
: [result]=h(result), [temp]=r(temp)
: [a]r(a), [c]r(c)
: lo);
You need an early clobber on temp since it is
--- Comment #17 from jakub at gcc dot gnu dot org 2008-10-02 19:40 ---
That bootstrapped/regtested, unfortunately the = in the assert is not right.
And when I've changed the = in the assert to , pr29581.f90 ICEs, it has
AM_NB_INDUCTION_VARS in one particular case set to 2, and
--- Comment #2 from simartin at gcc dot gnu dot org 2008-10-02 19:42
---
Introduced by my fix for PR29077
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-02 20:42
---
Building with -D_GLIBCXX_DEBUG reveals immediately at run-time that the code is
invalid.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
#include iostream
struct foo {
foo() { std::cout foo constructed\n; }
~foo() { std::cout foo destructed\n; }
};
enum opcode { NOP, FOO, DONE };
void exec0(const opcode* o) {
loop: switch (*o) {
case NOP: ++o; goto loop;
case FOO: { foo f; ++o; goto loop; }
--- Comment #5 from dje at gcc dot gnu dot org 2008-10-02 20:47 ---
This patch causes G++ to crash building some applications on AIX. Apparently a
version of G++ including this patch is being distributed and users are
reporting problems.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-10-02 20:49 ---
This testcase fails on the trunk for x86-darwin with an ICE:
/Users/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/pr37713.c:8:
internal compiler error: in set_mem_alias_set, at emit-rtl.c:1784^M
Please
--- Comment #4 from ivranos at freemail dot gr 2008-10-02 21:09 ---
May you be more specific and tell what exactly is invalid? That is what is the
error in the source code.
--
ivranos at freemail dot gr changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-02 21:22 ---
EH lowering for some reason does not copy the finally part of the try before
the goto. This also happens with 3.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dje at gcc dot gnu dot org 2008-10-02 21:30 ---
+ strip = (char *)ggc_alloc_string (name, len);
+
+ for (len = 0; name[len]; len++)
+if (name[len] == '$')
+ strip[len] = '_';
+else
+ strip[len] = name[len];
+ strip[len] = 0;
+
+ return strip;
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-02 21:32 ---
Looks like expansion creates some weirdo MEM_ALIAS_SET for the target. Some
RTL problem, not mine to investigate right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37713
--- Comment #2 from kargl at gcc dot gnu dot org 2008-10-02 21:47 ---
(In reply to comment #1)
Mine. The alias-oracle doesn't use PTA information yet.
Richard, I'm not sure how familiar you are with the Fortran
standard, so I'll just give a quick note. The standard forbids
the
Thee following program gives wrong results for some of the array
elements in an assignment when there is an overlap between the
left hand and right hand arrays. The errors sometimes move around
as I modified the code (although I've changed enough things that
I can't reproduce different failures.
--- Comment #5 from paolo dot carlini at oracle dot com 2008-10-02 22:18
---
Why should I do this work for you? This is not an help line, the only purpose
of Bugzilla is tracking and fixing bugs, I'm maintaining the library and given
the diagnostic provided by debug-mode (which exists
--- Comment #10 from spop at gcc dot gnu dot org 2008-10-02 22:50 ---
Subject: Bug 37485
Author: spop
Date: Thu Oct 2 22:48:46 2008
New Revision: 140844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140844
Log:
2008-10-02 Jan Sjodin [EMAIL PROTECTED]
Harsha
--- Comment #4 from aran at 100acres dot us 2008-10-02 23:06 ---
Created an attachment (id=16456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16456action=view)
NetBSD patch for SVN trunk
Obsoletes both prior patches. Patch for SVN trunk. Adds other NetBSD support
(e.g.,
--- Comment #6 from ivranos at freemail dot gr 2008-10-02 23:34 ---
The bug can easily be in the library.
--
ivranos at freemail dot gr changed:
What|Removed |Added
--- Comment #7 from ivranos at freemail dot gr 2008-10-02 23:37 ---
To be more precise: I believe the bug is in the library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37721
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-10-03 00:09 ---
Nope, your copy constructor causes the crash. It is not really doing a copy of
the struct but causing a random placement to happen so operator will return
different result when we do a copy between values and such.
--- Comment #5 from aran at 100acres dot us 2008-10-03 01:51 ---
Created an attachment (id=16457)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16457action=view)
Same fixes, but work
Final fixes. Sorry for the repeated posts.
--
aran at 100acres dot us changed:
--- Comment #1 from jason at redhat dot com 2008-10-03 02:27 ---
Subject: Re: New: Demangling of variadic functions
I've been working on a bunch of mangling/demangling issues lately, this
among them.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718
--- Comment #3 from simartin at gcc dot gnu dot org 2008-10-03 03:38
---
Patch submitted here
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00079.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37647
When I was upgrading the PS3 toolchain I found it would have been useful to
figure out which field of a struct was being initialized with this warning
turned on.
Take:
struct f
{
int *a;
};
char b[10];
struct f g = {b};
--- CUT ---
Currently we just get:
t.c:7: warning: initialization from
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-03 05:39 ---
I wonder why error_init/pedwarn_init/warning_init are not used in
WARN_FOR_ASSIGNMENT.
This would fix the issue ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37724
94 matches
Mail list logo
