How to make a array aligned with 16 byte
Can I make a array aligned with 16 byte at RTL pass? Thanks! -- Jianzhang Peng
Re: identifying indirect references in a loop
On Fri, Dec 11, 2009 at 5:16 AM, Aravinda aravindakida...@gmail.com wrote:
Hi,
Im trying to identify all indirect references in a loop so that, after
this analysis, I have a list of tree_nodes of pointer_type that are
dereferenced in a loop along with their step size, if any.
E.g.
while(i++ n)
{
*(p+i);
}
I want to get the pointer_type_node for 'p' and identify the step size
as '1', since 'i' has a step size of 1.
I am able to identify 'INDIRECT_REF' nodes in the loop. But since
these are generally the expression_temporaries, I will not get the
tree_node for 'p'. But I believe INDIRECT_REF is an expression who's
arg0 is an SSA_NAME node from which I will be able to use the
SSA_NAME_DEF_STMT to ultimately reach the tree_node for 'p'.
But I dont know how to get the SSA_NAME node from the given
INDIRECT_REF. Could someone please point out how to do this.
Also, I find it very difficult to know how the tree_nodes and types
are contained one within the other. Is there a general technique by
which I can know when a tree node will be nested within another and
how to retrieve them ?
Look into the tree.def file. Operands can be retrieved with the
TREE_OPERAND macro (see tree.h). So if you have an
INDIRECT_REF expression tree node you can get the
variable or SSA_NAME that is dereferenced using TREE_OPERAND (e, 0)
if e is the INDIRECT_REF expression tree. The pointer type
is then simply TREE_TYPE of that operand.
Btw, I think you want to use the existing data dependence analysis
which provides you with a list of data references in a loop.
See tree-data-ref.[ch].
Richard.
Thanks,
Aravinda
[RFC] LTO and debug information
The following draft patch disables the debuginfo disabling when using
-flto or -fwhopr and fixes up things so that for C debugging (mostly)
works.
The main question I have is how to proceed further here (with the
goal that simple debugging should be possible in 4.5). If we
apply this patch then we expose ICEs when -flto is used in
conjunction with -g because the patch doesn't fix all clashes
between free-lang-data and dwarf2out. Now I was thinking of
instead of ICEing to sorry () if we ICE, have debuginfo enabled
and had run free-lang-data. Or to keep -g non-operational for
LTO and add a -glto or -fi-really-want-to-debug option.
Or of course hope I can reasonably fix the ICEs I run into and
deal with the remaining cases as bugs?
The patch has proven useful debugging miscompiles in its current
state already.
Thanks,
Richard.
2009-12-11 Richard Guenther rguent...@suse.de
* tree.c (free_lang_data_in_binfo): Do not free BINFO_OFFSET
and BINFO_VPTR_FIELD.
(free_lang_data_in_decl): Do not free DECL_SIZE_UNIT,
DECL_SIZE, DECL_FIELD_OFFSET and DECL_FCONTEXT.
(free_lang_data): Do not disable debuginfo.
* lto-streamer-out.c (write_symbol_vec): Deal with
non-constant DECL_SIZE.
* dwarf2out.c (add_pure_or_virtual_attribute): Check for
DECL_CONTEXT.
(gen_type_die_for_member): Test for TYPE_STUB_DECL.
* opts.c (decode_options): Do not disable var-tracking for lto.
lto/
* lto.c (lto_fixup_field_decl): Fixup DECL_FIELD_OFFSET.
(lto_post_options): Do not disable debuginfo.
Index: gcc/tree.c
===
*** gcc/tree.c (revision 155164)
--- gcc/tree.c (working copy)
*** free_lang_data_in_binfo (tree binfo)
*** 4152,4164
gcc_assert (TREE_CODE (binfo) == TREE_BINFO);
- BINFO_OFFSET (binfo) = NULL_TREE;
BINFO_VTABLE (binfo) = NULL_TREE;
- BINFO_VPTR_FIELD (binfo) = NULL_TREE;
BINFO_BASE_ACCESSES (binfo) = NULL;
BINFO_INHERITANCE_CHAIN (binfo) = NULL_TREE;
BINFO_SUBVTT_INDEX (binfo) = NULL_TREE;
- BINFO_VPTR_FIELD (binfo) = NULL_TREE;
for (i = 0; VEC_iterate (tree, BINFO_BASE_BINFOS (binfo), i, t); i++)
free_lang_data_in_binfo (t);
--- 4152,4161
*** free_lang_data_in_decl (tree decl)
*** 4376,4404
}
}
! if (TREE_CODE (decl) == PARM_DECL
! || TREE_CODE (decl) == FIELD_DECL
! || TREE_CODE (decl) == RESULT_DECL)
! {
! tree unit_size = DECL_SIZE_UNIT (decl);
! tree size = DECL_SIZE (decl);
! if ((unit_size TREE_CODE (unit_size) != INTEGER_CST)
! || (size TREE_CODE (size) != INTEGER_CST))
! {
! DECL_SIZE_UNIT (decl) = NULL_TREE;
! DECL_SIZE (decl) = NULL_TREE;
! }
!
! if (TREE_CODE (decl) == FIELD_DECL
! DECL_FIELD_OFFSET (decl)
! TREE_CODE (DECL_FIELD_OFFSET (decl)) != INTEGER_CST)
! DECL_FIELD_OFFSET (decl) = NULL_TREE;
!
! /* DECL_FCONTEXT is only used for debug info generation. */
! if (TREE_CODE (decl) == FIELD_DECL)
! DECL_FCONTEXT (decl) = NULL_TREE;
! }
! else if (TREE_CODE (decl) == FUNCTION_DECL)
{
if (gimple_has_body_p (decl))
{
--- 4373,4379
}
}
! if (TREE_CODE (decl) == FUNCTION_DECL)
{
if (gimple_has_body_p (decl))
{
*** free_lang_data (void)
*** 4973,4985
diagnostic_finalizer (global_dc) = default_diagnostic_finalizer;
diagnostic_format_decoder (global_dc) = default_tree_printer;
- /* FIXME. We remove sufficient language data that the debug
- info writer gets completely confused. Disable debug information
- for now. */
- debug_info_level = DINFO_LEVEL_NONE;
- write_symbols = NO_DEBUG;
- debug_hooks = do_nothing_debug_hooks;
-
return 0;
}
--- 4948,4953
Index: gcc/lto-streamer-out.c
===
*** gcc/lto-streamer-out.c (revision 155164)
--- gcc/lto-streamer-out.c (working copy)
*** write_symbol_vec (struct lto_streamer_ca
*** 2350,2356
break;
}
! if (kind == GCCPK_COMMON DECL_SIZE (t))
size = (((uint64_t) TREE_INT_CST_HIGH (DECL_SIZE (t))) 32)
| TREE_INT_CST_LOW (DECL_SIZE (t));
else
--- 2349,2357
break;
}
! if (kind == GCCPK_COMMON
! DECL_SIZE (t)
! TREE_CODE (DECL_SIZE (t)) == INTEGER_CST)
size = (((uint64_t) TREE_INT_CST_HIGH (DECL_SIZE (t))) 32)
| TREE_INT_CST_LOW (DECL_SIZE (t));
else
Index: gcc/dwarf2out.c
===
*** gcc/dwarf2out.c (revision 155164)
--- gcc/dwarf2out.c (working copy)
*** add_pure_or_virtual_attribute (dw_die_re
*** 16476,16482
Re: generate RTL sequence
Joern Rennecke amyl...@spamcop.net writes: If you need more rigid scheduling, you can use CC0. No, please don't. I accept that CC0 is necessary today for a few processors, but I really don't think we should encourage any new uses of it. Ian
Bitfields problem
As I continue my work on the machine description file, I currently
worked on the bitfields again to try to get a good code generation
working. Right now, I've followed what was done in the ia64 for signed
extractions :
(define_insn extv
[(set (match_operand:DI 0 gr_register_operand =r)
(sign_extract:DI (match_operand:DI 1 gr_register_operand r)
(match_operand:DI 2 extr_len_operand n)
(match_operand:DI 3 shift_count_operand M)))]
extr %0 = %1, %3, %2
[(set_attr itanium_class ishf)])
now this works for me except that I get for this code:
typedef struct sTest {
int64_t a:1;
int64_t b:5;
int64_t c:7;
int64_t d:15;
}STest;
int64_t bar2 (STest a)
{
int64_t res = a.d;
return res;
}
Here is what I get at the final cleanup:
;; Function bar2 (bar2)
bar2 (a)
{
short unsigned int SR.44;
short unsigned int SR.43;
short unsigned int SR.41;
short unsigned int SR.40;
short unsigned int SR.22;
short unsigned int SR.3;
bb 2:
SR.22 = (short unsigned int) (unnamed-signed:15) ((short unsigned
int) a.d 32767);
SR.43 = SR.22 32767;
SR.44 = SR.43 ^ 16384;
SR.3 = (short unsigned int) (unnamed-signed:15) ((short unsigned
int) (unnamed-signed:15) (SR.44 + 49152) 32767);
SR.40 = SR.3 32767;
SR.41 = SR.40 ^ 16384;
return (int64_t) (unnamed-signed:15) (SR.41 + 49152);
}
I don't understand why I get all these instructions. I know that
because it's signed, it is more complicated but I would prefer to get
an unsigned extract and the a shift left/shift right. Thus 3
instructions.
Right now, I get so many more instructions that represent what I
showed from the final cleanup.
Any reason for all these instructions or ideas on how to get to my 3
instructions ?
Thank you for your help and time,
Jean Christophe Beyler
Dwarf announcements mailing list
The public comment draft of the DWARF Version 4 Standard should be available some time next month. It will be on the DWARF website: http://dwarfstd.org. If you want to receive a notification when this is available, please sign up on the DWARF announcements mailing list: http://lists.dwarfstd.org/listinfo.cgi/dwarf-announce-dwarfstd.org -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Vectorizing 16bit signed integers
Hi
I hope someone can help me. I've been trying to write some tight integer loops
in way that could be auto-vectorized, saving me to write assembler or using
specific vectorization extensions. Unfortunately I've not yet managed to make
gcc vectorize any of them.
I've simplified the case to just perform the very first operation in the loop;
converting from two's complement to sign-and-magnitude.
I've then used -ftree-vectorizer-verbose to examine if and if not, why not the
loops were not vectorized, but I am afraid I don't understand the output.
The simplest version of the loop is here (it appears the branch is not a
problem, but I have another version without).
inline uint16_t transsign(int16_t v) {
if (v0) {
return 0x8000U | (1-v);
} else {
return v;
}
}
It very simply converts in a fashion that maintains the full effective bit-
width.
The error from the vectorizer is:
vectorizesign.cpp:42: note: not vectorized: relevant stmt not supported:
v.1_16 = (uint16_t) D.2157_11;
It appears the unsupported operation in vectorization is the typecast from
int16_t to uint16_t, can this really be the case, or is the output misleading?
If it is the case, then is there good reason for it, or can I fix it myself by
adding additional vectorizable operations?
I've attached both test case and full output of ftree-vectorized-verbose=9
Best regards
`Allan
#include stdint.h
inline uint16_t transsign1(int16_t v) {
// written with no control-flow to facilitate auto-vectorization
uint16_t sv = v 15; // signed left-shift gives a classic sign selector -1 or 0
sv = sv 0x7FFFU; // never invert the sign-bit
return v ^ sv; // conditional invertion by xor
}
inline uint16_t transsign2(int16_t v) {
if (v0) {
return 0x8000U | ~v;
} else {
return v;
}
}
inline uint16_t transsign3(int16_t v) {
if (v0) {
return 0x8000U | (1-v);
} else {
return v;
}
}
// candidate for vectorizaton
void convertts1(uint16_t* out, int16_t* in, uint32_t len) {
for(unsigned int i=0;ilen;++i) {
out[i] = transsign1(in[i]);
}
}
// candidate for vectorizaton
void convertts2(uint16_t* out, int16_t* in, uint32_t len) {
for(unsigned int i=0;ilen;++i) {
out[i] = transsign2(in[i]);
}
}
// candidate for vectorizaton
void convertts3(uint16_t* out, int16_t* in, uint32_t len) {
for(unsigned int i=0;ilen;++i) {
out[i] = transsign3(in[i]);
}
}
gcc: 2: No such file or directory
vectorizesign.cpp:28: note: = analyze_loop_nest =
vectorizesign.cpp:28: note: === vect_analyze_loop_form ===
vectorizesign.cpp:28: note: split exit edge.
vectorizesign.cpp:28: note: === get_loop_niters ===
vectorizesign.cpp:28: note: == get_loop_niters:len_3(D)
vectorizesign.cpp:28: note: Symbolic number of iterations is len_3(D)
vectorizesign.cpp:28: note: === vect_analyze_data_refs ===
vectorizesign.cpp:28: note: get vectype with 8 units of type short int
vectorizesign.cpp:28: note: vectype: vector short int
vectorizesign.cpp:28: note: get vectype with 8 units of type short unsigned int
vectorizesign.cpp:28: note: vectype: vector short unsigned int
vectorizesign.cpp:28: note: === vect_analyze_scalar_cycles ===
vectorizesign.cpp:28: note: Analyze phi: i_16 = PHI i_14(5), 0(3)
vectorizesign.cpp:28: note: Access function of PHI: {0, +, 1}_1
vectorizesign.cpp:28: note: step: 1, init: 0
vectorizesign.cpp:28: note: Detected induction.
vectorizesign.cpp:28: note: Analyze phi: SMT.12_27 = PHI SMT.12_26(5),
SMT.12_25(D)(3)
vectorizesign.cpp:28: note: === vect_pattern_recog ===
vectorizesign.cpp:28: note: vect_is_simple_use: operand i_16
vectorizesign.cpp:28: note: def_stmt: i_16 = PHI i_14(5), 0(3)
vectorizesign.cpp:28: note: type of def: 4.
vectorizesign.cpp:28: note: === vect_mark_stmts_to_be_vectorized ===
vectorizesign.cpp:28: note: init: phi relevant? i_16 = PHI i_14(5), 0(3)
vectorizesign.cpp:28: note: init: phi relevant? SMT.12_27 = PHI SMT.12_26(5),
SMT.12_25(D)(3)
vectorizesign.cpp:28: note: init: stmt relevant? D.2120_5 = i_16 * 2;
vectorizesign.cpp:28: note: init: stmt relevant? D.2121_7 = out_6(D) + D.2120_5;
vectorizesign.cpp:28: note: init: stmt relevant? D.2122_10 = in_9(D) + D.2120_5;
vectorizesign.cpp:28: note: init: stmt relevant? D.2123_11 = *D.2122_10;
vectorizesign.cpp:28: note: init: stmt relevant? D.2124_12 = (int) D.2123_11;
vectorizesign.cpp:28: note: init: stmt relevant? D.2170_17 = D.2124_12 15;
vectorizesign.cpp:28: note: init: stmt relevant? sv_18 = (uint16_t) D.2170_17;
vectorizesign.cpp:28: note: init: stmt relevant? sv_19 = sv_18 32767;
vectorizesign.cpp:28: note: init: stmt relevant? sv.0_20 = (short int) sv_19;
vectorizesign.cpp:28: note: init: stmt relevant? D.2167_21 = sv.0_20 ^
D.2123_11;
vectorizesign.cpp:28: note: init: stmt relevant? D.2166_22 = (uint16_t)
D.2167_21;
vectorizesign.cpp:28: note: init: stmt relevant? *D.2121_7 = D.2166_22;
vectorizesign.cpp:28: note:
Re: Bitfields problem
Interestingly enough, if I do this instead:
typedef struct sTest {
int a:12;
int b:20;
int c:7;
int d:15;
}STest;
int64_t bar2 (STest *a)
{
int64_t res = a-b;
return res;
}
I get at the expand pass :
(insn 6 5 7 3 struct3.c:27 (set (reg:SI 75)
(mem/s:SI (reg/v/f:DI 73 [ a ]) [0 S4 A32])) -1 (nil)) -
Actually get the data
(insn 7 6 8 3 struct3.c:27 (set (reg:DI 77)
(zero_extract:DI (subreg:DI (reg:SI 75) 0)
(const_int 20 [0x14])
(const_int 12 [0xc]))) -1 (nil)) - Extract the
bits we want but this is zero_extracted
(insn 8 7 9 3 struct3.c:27 (set (reg:DI 78)
(ashift:DI (reg:DI 77)
(const_int 43 [0x2b]))) -1 (nil))
(insn 9 8 10 3 struct3.c:27 (set (subreg:DI (reg:SI 76) 0)
(ashiftrt:DI (reg:DI 78)
(const_int 43 [0x2b]))) -1 (nil)) - These two
instructions actually sign extend it
(insn 10 9 11 3 struct3.c:27 (set (reg:DI 79)
(ashift:DI (reg:SI 76)
(const_int 32 [0x20]))) -1 (nil))
(insn 11 10 12 3 struct3.c:27 (set (reg:DI 74)
(ashiftrt:DI (reg:DI 79)
(const_int 32 [0x20]))) -1 (expr_list:REG_EQUAL
(sign_extend:DI (reg:SI 76))
(nil))) - Because it's seen as a SI, these last two sign
extend it again...
And I get later on in the passes (the instructions are removed by the
combine pass):
(insn 6 3 7 2 struct3.c:27 (set (reg:SI 75)
(mem/s:SI (reg:DI 8 r8 [ a ]) [0 S4 A32])) 74
{movsi_internal2} (expr_list:REG_DEAD (reg:DI 8 r8 [ a ])
(nil)))
(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 9 2 NOTE_INSN_DELETED)
(note 9 8 10 2 NOTE_INSN_DELETED)
(note 10 9 11 2 NOTE_INSN_DELETED)
(note 11 10 16 2 NOTE_INSN_DELETED)
(insn 16 11 22 2 struct3.c:30 (set (reg/i:DI 6 r6)
(zero_extract:DI (subreg:DI (reg:SI 75) 0)
(const_int 20 [0x14])
(const_int 12 [0xc]))) 63 {extzvdi} (expr_list:REG_DEAD (reg:SI 75)
(nil)))
So now I have two issues that I can't seem to figure out :
- Why can combine remove these 4 instructions ?
- Why do I have such a difference between a local variable that is not
a pointer, a pointer and a global variable ?
I remember having a different behavior if the variable was a global
variable or if it was a parameter. It seems that this is the case also
for here. However, this is worse, since it transforms my signed
extract into a simple zero_extract.
Thanks for your help,
Jc
PS: here is the combine pass debug information:
;; Function bar2 (bar2)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
insn_cost 2: 4
insn_cost 6: 4
insn_cost 7: 36
insn_cost 8: 4
insn_cost 9: 4
insn_cost 10: 4
insn_cost 11: 4
insn_cost 16: 4
insn_cost 22: 0
deferring deletion of insn with uid = 2.
modifying insn i3 6 r75:SI=[r8:DI]
REG_DEAD: r8:DI
deferring rescan insn with uid = 6.
deferring deletion of insn with uid = 8.
modifying insn i3 9 r76:SI#0=r77:DI
REG_DEAD: r77:DI
deferring rescan insn with uid = 9.
deferring deletion of insn with uid = 7.
modifying insn i3 9 r76:SI#0=zero_extract(r75:SI#0,0x14,0xc)
REG_DEAD: r75:SI
deferring rescan insn with uid = 9.
deferring deletion of insn with uid = 10.
modifying insn i311 r74:DI=r76:SI#00xf
REG_DEAD: r76:SI
deferring rescan insn with uid = 11.
deferring deletion of insn with uid = 9.
modifying insn i311 r74:DI=zero_extract(r75:SI#0,0x14,0xc)
REG_DEAD: r75:SI
deferring rescan insn with uid = 11.
deferring deletion of insn with uid = 11.
modifying insn i316 r6:DI=zero_extract(r75:SI#0,0x14,0xc)
REG_DEAD: r75:SI
deferring rescan insn with uid = 16.
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 3 2 NOTE_INSN_DELETED)
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 struct3.c:27 (set (reg:SI 75)
(mem/s:SI (reg:DI 8 r8 [ a ]) [0 S4 A32])) 74
{movsi_internal2} (expr_list:REG_DEAD (reg:DI 8 r8 [ a ])
(nil)))
(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 9 2 NOTE_INSN_DELETED)
(note 9 8 10 2 NOTE_INSN_DELETED)
(note 10 9 11 2 NOTE_INSN_DELETED)
(note 11 10 16 2 NOTE_INSN_DELETED)
(insn 16 11 22 2 struct3.c:30 (set (reg/i:DI 6 r6)
(zero_extract:DI (subreg:DI (reg:SI 75) 0)
(const_int 20 [0x14])
(const_int 12 [0xc]))) 63 {extzvdi} (expr_list:REG_DEAD (reg:SI 75)
(nil)))
(insn 22 16 0 2 struct3.c:30 (use (reg/i:DI 6 r6)) -1 (nil))
starting the processing of deferred insns
deleting insn with uid = 2.
deleting insn with uid = 7.
deleting insn with uid = 8.
deleting insn with uid = 9.
deleting insn with uid = 10.
deleting insn with uid = 11.
rescanning insn with uid = 6.
deleting insn with uid = 6.
rescanning insn with uid = 16.
deleting insn with uid = 16.
ending the processing of deferred insns
;; Combiner totals: 16 attempts, 16 substitutions (2 requiring new space),
;; 6 successes.
On Fri, Dec 11, 2009 at 11:57 AM, Jean Christophe
Re: Bad mailing list index?
On 10/12/2009 7:43 a.m., H.J. Lu wrote: Hi, When I visit: http://gcc.gnu.org/ml/gcc-bugs/ http://gcc.gnu.org/ml/gcc-cvs/ at Wed Dec 9 10:41:43 PST 2009, I didn't see December, 2009. It was there yesterday. Has anyone else seen it? You may need to clear browser cache first. The page sends a Last-Modified time but no Expires header, so some aggressive proxies, browsers and other caches could end up caching it for a long time. Adding an Expires header set for the 1st of the next month would be a good idea. Cheers, Nicholas Sherlock
[Bug c++/42350] The attached file causes an internal compiler error
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-12-11 09:30 --- there's no ICE with 4.1.2 or 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42350
[Bug regression/42351] 64 bit arm gcc consumes huge memory
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-11 09:53 --- Is a dup of PR41399 *** This bug has been marked as a duplicate of 41399 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42351
[Bug target/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c
--- Comment #15 from ramana at gcc dot gnu dot org 2009-12-11 09:53 --- *** Bug 42351 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||carrot at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
[Bug bootstrap/42093] bootstrap hangs in stage2 run of build/gengtype
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Priority|P3 |P2 Last reconfirmed|2009-11-20 16:00:02 |2009-12-11 10:17:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug target/41939] EABI violation in accessing values below the stack.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-11 10:31 --- Subject: Bug 41939 Author: ramana Date: Fri Dec 11 10:31:13 2009 New Revision: 155154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155154 Log: 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/41939 Backport from mainline: 2009-06-05 Julian Brown jul...@codesourcery.com * config/arm/ieee754-df.S (cmpdf2): Avoid writing below SP. * config/arm/ieee754-sf.S (cmpsf2): Likewise. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/ieee754-df.S branches/gcc-4_4-branch/gcc/config/arm/ieee754-sf.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41939
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-12-11 10:39 --- (In reply to comment #4) But I'm not convinced that doing this is always a mistake. Since we don't care about the object, we must care about the constructor side effect. I seem to be under the impression that ISO C++ allows the construction of temporary objects to be optimized away---even if there are side effects in the constructor or destructor! Therefore, it's hard to see a valid use case for this. Certain temporaries (such as those created during copying or reference binding) can be optimised away, I don't think it's true of temporaries created explicitly like this. e.g. I think this should work: std::ofstream(lockfile); // creates ./lockfile if it doesn't exist (assuming write permission in the directory, and ignoring races and other reasons it might be a bad idea) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug middle-end/42320] link error with -flto (undefined reference to 'non-virtual thunk ...)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-11 10:56 --- Subject: Bug 42320 Author: rguenth Date: Fri Dec 11 10:56:17 2009 New Revision: 155155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155155 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/42320 * lto-symtab.c (lto_symtab_resolve_can_prevail_p): Properly detect non-prevailing decls. * g++.dg/lto/20091210-1_0.h: New testcase. * g++.dg/lto/20091210-1_0.C: Likewise. * g++.dg/lto/20091210-1_1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/20091210-1_0.C trunk/gcc/testsuite/g++.dg/lto/20091210-1_0.h trunk/gcc/testsuite/g++.dg/lto/20091210-1_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-symtab.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42320
[Bug middle-end/42320] link error with -flto (undefined reference to 'non-virtual thunk ...)
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-11 10:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42320
[Bug middle-end/42228] [4.5 Regression] verify_cgraph_node failed:node has wrong clone_of
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-12-11 11:17 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42228
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-12-11 11:17 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code [4.4 only]
--- Comment #11 from ramana at gcc dot gnu dot org 2009-12-11 11:21 --- Subject: Bug 41574 Author: ramana Date: Fri Dec 11 11:21:33 2009 New Revision: 155157 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155157 Log: Fix PR41574 on 4.4 branch. 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com 2009-10-05 Doug Kwan dougk...@google.com PR rtl-optimization/41574 * combine.c (distribute_and_simplify_rtx): Quit if RTX mode is floating point and we are not doing unsafe math optimizations. 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com 2009-10-08 Doug Kwan dougk...@google.com PR rtl-optimization/41574 * gcc.dg/pr41574.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41574.c - copied unchanged from r152580, trunk/gcc/testsuite/gcc.dg/pr41574.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/combine.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug tree-optimization/42250] [4.5 Regression] segfault in ipa-type-escape.c for several cpu2000 tests
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-12-11 11:30 --- I am testing the attached patch. We should not re-walk bodies of clones. I wonder if this makes struct-reorg useable? Honza Index: ipa-type-escape.c === --- ipa-type-escape.c (revision 155138) +++ ipa-type-escape.c (working copy) @@ -1984,7 +1984,7 @@ type_escape_execute (void) they may cause a type variable to escape. */ for (node = cgraph_nodes; node; node = node-next) -if (node-analyzed) +if (node-analyzed !node-clone_of) analyze_function (node); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42250
[Bug middle-end/42177] [C++0x] ICE in function_and_variable_visibility, at ipa.c:296
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-12-11 11:34 --- Seems to work in today snapshot. The ICE meant visibility bug produced by frotnend, so probably it was fixed in meantime. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42177
[Bug tree-optimization/41835] ICE with -flto -O3 (BB N can not throw but has an EH edge)
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-12-11 11:37 --- ipa nothrow is hidden in ipa-pure-const (that should be renamed eventually). However issue here is that at IPA stage we should not touch function bodies, so we should not do these updates. This is why fixup pass exists to resolve these cases after we get into local compilation. This however seems like LTO is getting something wrong, we do make throw flags to disappear at IPA for quite some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41835
[Bug lto/41756] LTO: -flto -O1 linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-12-11 11:39 --- I would vote for LTO frotnend simply sorrying when seeing units with and without exceptions. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug target/42074] gcc.dg/torture/builtin-math-7.c fails on darwin
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-12-11 11:46 --- This is now darwin specific, the lto issue is PR41915. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|lto |target GCC target triplet||x86_64-apple-darwin10 Summary|gcc.dg/torture/builtin-math-|gcc.dg/torture/builtin-math- |7.c fails with -flto or - |7.c fails on darwin |fwhopr | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug lto/41915] FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto execution test
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-11 11:49 --- Confirmed. Fails everywhere. The issue is that flag_complex_method is not the same in lto1 compared to cc1 so we lower the complex multiplication differently. The specific issue is that we fold D.2036_6 = __complex__ ( Inf, 0.0) * __complex__ (0.0, 1.0e+0); D.2035_7 = D.2036_6 * D.2036_6; to D.2036_6 = COMPLEX_EXPR Nan, Inf; D.2035_7 = COMPLEX_EXPR Nan, Nan; with -fcx-fortran-rules (flag_complex_method == 1). So the particular issue is a middle-end one while the general flag_complex_method issue remains. In the end we need to move flag_complex_method into the IL just like flag_wrapv. I'm going to try fix the testcase at least. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-11 11:49:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41915
[Bug target/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code [4.4 only]
--- Comment #9 from ramana at gcc dot gnu dot org 2009-12-11 11:54 --- Subject: Bug 41196 Author: ramana Date: Fri Dec 11 11:53:46 2009 New Revision: 155158 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155158 Log: Fix target/41196 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/41196 2009-10-14 Daniel Gutson dgut...@codesourcery.com * config/arm/neon.md (neon_vshll_nmode): Checking Bounds fixed. 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/41196 2009-10-14 Daniel Gutson dgut...@codesourcery.com * testsuite/gcc.target/arm/neon/vfp-shift-a2t2.c: New test case. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/neon.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41196
[Bug target/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code [4.4 only]
--- Comment #10 from ramana at gcc dot gnu dot org 2009-12-11 11:54 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41196
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
--- Comment #6 from kkylheku at gmail dot com 2009-12-11 11:57 --- (In reply to comment #5) (In reply to comment #4) But I'm not convinced that doing this is always a mistake. Since we don't care about the object, we must care about the constructor side effect. I seem to be under the impression that ISO C++ allows the construction of temporary objects to be optimized away---even if there are side effects in the constructor or destructor! Therefore, it's hard to see a valid use case for this. Certain temporaries (such as those created during copying or reference binding) can be optimised away, I don't think it's true of temporaries created explicitly like this. I've gone over the relevant 14882:2003 sections and have come to the same conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug lto/41756] LTO: -flto -O1 linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-11 12:16 --- I wonder if we should simply ignore -fno-exceptions/-fexceptions passed to lto1 and rely on the automated discovery. The testcase btw works for me on i?86. The proposed patch would delete handling of OPT_fexceptions from register_user_option_p and add flag_exceptions = 0 to lto_init_options in case you can still reproduce the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression
--- Comment #7 from dodji at gcc dot gnu dot org 2009-12-11 12:25 --- Subject: Bug 42251 Author: dodji Date: Fri Dec 11 12:25:19 2009 New Revision: 155159 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155159 Log: Fix PR c++/42251 gcc/cp/ChangeLog: PR c++/42251 * pt.c (convert_template_argument): Avoid missing folding of SCOPE_REFs. gcc/testsuite/ChangeLog: PR c++/42251 * g++.dg/template/const3.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/const3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression
--- Comment #8 from dodji at gcc dot gnu dot org 2009-12-11 12:27 --- Fixed in 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-11
13:35 ---
(In reply to comment #1)
In general you can answer what we think is best by checking the llvm-gcc
sources from llvm, and in this case, we are using:
/* { dg-options -fnext-runtime -fno-constant-cfstrings } */
delete -fno-constant-cfstrings
For template-4.mm:
/* { dg-do run { target powerpc*-*-darwin* } } */
why is this being restricted to darwin (and powerpc at that)? The testcase
appears to cater for gnu runtime too...
/* { dg-require-effective-target ilp32 } */
Having said this -- we have a global problem with using ?lp32/64 in ObjC/ObjC++
testcases along with -fgnu-runtime. This flag causes xgcc/g++ to print a
warning - which means that these target supports tests always fail for
-fgnu-runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-12-11
14:08 ---
(In reply to comment #2)
(In reply to comment #1)
For template-4.mm:
/* { dg-do run { target powerpc*-*-darwin* } } */
why is this being restricted to darwin (and powerpc at that)? The testcase
appears to cater for gnu runtime too...
well.. it does work for -fgnu-runtime, on i686 darwin9 at least... so {
target powerpc*-*-darwin* } should probably be deleted.
However, it ONLY works if the compiler is installed -- objc/NXConstStr.h is not
found otherwise (this is a separate problem, of course).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug lto/41658] Execution testsuite fails with -O2 -fwhopr
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-11 14:25 --- The issue with strcpy-chk.c is that with WHOPR we end up streaming const char s1[] = 123; as DECL_WEAK which causes string_constant () to not look at DECL_INITIAL and thus the test fails. Likely the other two are similar. We do that here: make_decl_one_only (decl=0xb77d, comdat_group=0xb77c8a64) at /home/richard/src/trunk/gcc/varasm.c:5765 5762#ifdef MAKE_DECL_ONE_ONLY 5763 MAKE_DECL_ONE_ONLY (decl); 5764#endif which sets DECL_WEAK on elfos. Called from #0 make_decl_one_only (decl=0xb77d, comdat_group=0xb77c8a64) at /home/richard/src/trunk/gcc/varasm.c:5765 #1 0x083cbd8e in write_global_stream (ob=0x8dd8478, encoder=0x8d9a18c) at /home/richard/src/trunk/gcc/lto-streamer-out.c:2174 if (pointer_set_insert (decls_already_emitted, t)) make_decl_one_only (t, DECL_ASSEMBLER_NAME (t)); rather than making the decl one-only we should emit true external references here (or for this particular case localize the variable if we know its address is not refered to). We could maybe also resort to TREE_ASM_WRITTEN (that's the only thing that fixes this testcase). This bug isn't particularly bad but the testsuite FAILs are annoying at least. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | Keywords||lto, missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41658
[Bug lto/41657] FAIL: gcc.c-torture/execute/builtins/memmove-2.c compilation, -O2 -fwhopr
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-11 14:30 --- Seems to fail everywhere. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | Keywords||lto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41657
[Bug lto/41658] Execution testsuite fails with -O2 -fwhopr
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 14:33 --- I'm going to test the TREE_ASM_WRITTEN variant. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-10 17:08:53 |2009-12-11 14:33:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41658
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #6 from dodji at gcc dot gnu dot org 2009-12-11 14:36 --- Subject: Bug 42225 Author: dodji Date: Fri Dec 11 14:36:05 2009 New Revision: 155160 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155160 Log: Fix PR c++/42225 gcc/cp/ChangeLog: PR c++/42225 * typeck.c (incompatible_dependent_typedefs_p): New function. (structural_comptypes): Use it. * cp-tree.h (cp_set_underlying_type): Declare ... * tree.c (cp_set_underlying_type): ... new function. * class.c (build_self_reference): Use cp_set_underlying_type instead of set_underlying_type. * decl2.c (grokfield): Likewise. * name-lookup.c (pushdecl_maybe_friend): Likewise. gcc/testsuite/ChangeLog: PR c++/42225 * g++.dg/template/typedef24.C: New test. * g++.dg/template/typedef25.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef24.C trunk/gcc/testsuite/g++.dg/template/typedef25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #7 from dodji at gcc dot gnu dot org 2009-12-11 14:37 --- Fixed in trunk (4.5) -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug fortran/42335] [OOP] ICE on CLASS IS (bad_identifier)
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-11 14:40 --- Subject: Bug 42335 Author: janus Date: Fri Dec 11 14:40:36 2009 New Revision: 155162 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155162 Log: gcc/fortran/ 2009-12-11 Janus Weil ja...@gcc.gnu.org PR fortran/42335 * symbol.c (select_type_insert_tmp): Add an extra check for error recovery. gcc/testsuite/ 2009-12-11 Janus Weil ja...@gcc.gnu.org PR fortran/42335 * gfortran.dg/select_type_11.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/select_type_11.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42335
[Bug fortran/22552] Would like warning when an undeclared function is called
--- Comment #7 from dfranke at gcc dot gnu dot org 2009-12-11 14:42 --- Daniel, is there anything going to happen with those patches you attached? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
[Bug lto/41657] FAIL: gcc.c-torture/execute/builtins/memmove-2.c compilation, -O2 -fwhopr
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 14:35 --- I will look at this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-10 17:09:13 |2009-12-11 14:35:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41657
[Bug lto/41662] FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-11 14:46 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41662
[Bug lto/41662] FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 14:46 --- Subject: Bug 41662 Author: rguenth Date: Fri Dec 11 14:46:09 2009 New Revision: 155163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155163 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/41662 * lto-streamer-in.c (lto_init_eh): Move eh_initialized_p handling here. (input_eh_regions): Adjust. (lto_input_ts_function_decl_tree_pointers): Initialize EH if a non-NULL DECL_FUNCTION_PERSONALITY was read in. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41662
[Bug lto/41915] FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto execution test
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 14:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41915
[Bug lto/41915] FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto execution test
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-11 14:49 --- Subject: Bug 41915 Author: rguenth Date: Fri Dec 11 14:49:35 2009 New Revision: 155164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155164 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/41915 * lto-lang.c (lto_init_options): Initialize flag_complex_method to the C99 default. Do not set flag_unit_at_a_time. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-lang.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41915
[Bug fortran/22552] Would like warning when an undeclared function is called
--- Comment #8 from domob at gcc dot gnu dot org 2009-12-11 14:58 --- Well, on 10th of August I posted this to the mailing list to get comments about what to do with this PR and some other. I did so far never get any replies :) So actually I'd like to work things out here and either fix or close the PR. But I've no real plan at the moment because I'd like to get other's opinions. The patch itself seems fine to me, the point is whether we want that warning or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
[Bug fortran/42335] [OOP] ICE on CLASS IS (bad_identifier)
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-11 15:02 --- Fixed with r155162. Thanks for the report. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42335
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2009-12-11 15:32 --- Subject: Bug 36047 Author: mkuvyrkov Date: Fri Dec 11 15:32:08 2009 New Revision: 155165 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155165 Log: 2009-12-11 Sebastian Andrzej Siewior bige...@linutronix.de PR target/36047 * config/m68k/linux.h: Remove LABELNO from the mcount statement. It is not used by glibc/uclibc and does not work with large binaries. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/linux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2009-12-11 15:35 --- This is now fixed with the above patch by Sebastian. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-11 15:44 --- Nothing new. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug lto/42037] grow domain error in lto1
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-11 15:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42037
[Bug lto/42037] grow domain error in lto1
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-11 15:53 --- Subject: Bug 42037 Author: rguenth Date: Fri Dec 11 15:52:57 2009 New Revision: 155166 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155166 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/42037 * lto.c (lto_resolution_read): Properly grow the vector. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42037
[Bug fortran/42257] [OOP] Compiler segmentation fault due missing public statement
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-11 15:54 ---
Here is a patch which fixes the ICE:
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 155160)
+++ gcc/fortran/module.c(working copy)
@@ -4670,6 +4670,10 @@ write_equiv (void)
static void
write_dt_extensions (gfc_symtree *st)
{
+ if (!gfc_check_access (st-n.sym-attr.access,
+st-n.sym-ns-default_access))
+return;
+
mio_lparen ();
mio_pool_string (st-n.sym-name);
if (st-n.sym-module != NULL)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-03 07:32:13 |2009-12-11 15:54:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42257
[Bug lto/41670] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -fwhopr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-11 15:55 --- I believe this should get fixed with the fix for PR41657 I am going to check in soon. Please update this PR accordingly. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||41657 Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41670
[Bug fortran/41781] [OOP] bogus undefined label error with SELECT TYPE.
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-11 16:09 --- I think this one can be closed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41781
[Bug lto/36468] [LTO] ICE in force_decl_die, at dwarf2out.c:13976
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-11 16:21 --- I can't reproduce this, thus fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
[Bug c++/42219] [4.5 Regression] ICE with const void as parameter type
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-11 16:31 --- The problem is that we create a FUNCTION_TYPE with error_mark_node parameter type for error recovery, and then ptr_reasonably_similar tries to consider conversions that are almost right in order to give better error messages (and allow some with -fpermissive), and it thinks any function types are close enough without noticing that we're dealing with an erroneous one. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-30 03:39:26 |2009-12-11 16:31:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263, -O0 vs -Ox misses tree lowering phases
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-12-11 16:40 --- I can confirm the ICE from comment #8 still is present on i?86-linux. #1 0x0820c740 in expand_mult (mode=XCmode, op0=0x0, op1=0xb77d3ba0, target=0xb77d3b7c, unsignedp=0) at /home/richard/src/trunk/gcc/expmed.c:3253 3253 gcc_assert (op0); which is because expand_binop seems to fail. 3246 /* This used to use umul_optab if unsigned, but for non-widening multiply 3247 there is no difference between signed and unsigned. */ (gdb) l 3248 op0 = expand_binop (mode, 3249 ! unsignedp 3250 flag_trapv (GET_MODE_CLASS(mode) == MODE_INT) 3251 ? smulv_optab : smul_optab, 3252 op0, op1, target, unsignedp, OPTAB_LIB_WIDEN); 3253 gcc_assert (op0); expand_binop (mode=XCmode, binoptab=0x8c72de0, op0=0xb77d3b88, op1=0xb77d3ba0, target=0xb77d3b7c, unsignedp=0, methods=OPTAB_LIB_WIDEN) at /home/richard/src/trunk/gcc/optabs.c:1552 (gdb) call debug_rtx (op0) (mem/s/c:XC (plus:SI (reg/f:SI 54 virtual-stack-vars) (const_int -32 [0xffe0])) [0 w+0 S24 A32]) (gdb) call debug_rtx (op1) (mem/s/c:XC (plus:SI (reg/f:SI 54 virtual-stack-vars) (const_int -64 [0xffc0])) [0 z+0 S24 A32]) (gdb) call debug_rtx (target) (concat:XC (reg:XF 80 [ D.2040 ]) (reg:XF 81 [ D.2040+12 ])) the optab expansion fails because there is no optab_libfunc for smul_optab and XCmode or TCmode. We arrive here because at -O1 we lower complex operations after writing LTO IL and at -O0 we do so before. So if you combine that we never lower complex operations properly. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2009-09-17 09:44:37 |2009-12-11 16:40:07 date|| Summary|[LTO] ICE in expand_shift, |[LTO] ICE in expand_shift, |at expmed.c:2263|at expmed.c:2263, -O0 vs -Ox ||misses tree lowering phases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
[Bug lto/39000] internal compiler error: in output_expr_operand, at lto-function-out.c:1200
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 16:42 --- Works for me with a cross. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39000
[Bug target/42074] gcc.dg/torture/builtin-math-7.c fails on darwin
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-11 16:44 --- The Darwin issue is being tracked in PR42333. Since the LTO issue is fixed, to avoid confusion I'll close this one as a dup. *** This bug has been marked as a duplicate of 42333 *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #31 from ghazi at gcc dot gnu dot org 2009-12-11 16:44 --- *** Bug 42074 has been marked as a duplicate of this bug. *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug lto/40818] internal compiler error: in lto_output_tree_ref, at lto-streamer-out.c:821
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-11 16:47 --- Fixed thus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40818
[Bug lto/41376] collect2 (and maybe lto1) do not handle static libraries
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-11 16:50 --- It works when you use the linker plugin -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-11 16:50:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
[Bug lto/41554] -flto and -fwhopr should be moved to common.opt
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-11 16:54 --- Fixed. -Wabi and -Wpsabi is a non-LTO specific issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41554
[Bug lto/41591] documentation should document interaction of -flto and -fwhole-program
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-11 16:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41591
[Bug lto/41593] slightly confusing configure message about lto
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-11 16:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41593
[Bug libstdc++/22634] [DR 539] partial_sum is too constrained
--- Comment #19 from paolo dot carlini at oracle dot com 2009-12-11 17:02 --- This is now [Ready]: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539 and we are already *almost* doing the right thing, besides a std::move call in std::adjacent_difference, which I'm going to add... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #8 from jacob dot benoit dot 1 at gmail dot com 2009-12-11 17:07 --- (In reply to comment #7) Fixed in trunk (4.5) Thanks for fixing this bug! Maybe I'm just ignorant, but I can't get the fix to work for me. I have SVN r155167. I am still getting a ICE, albeit at a slightly different line number now: # 12:01:44 ~/build/eigen$ make product_small_1 Building CXX object test/CMakeFiles/product_small_1.dir/product_small.cpp.o In file included from /home/bjacob/eigen/test/product_small.cpp:26:0: /home/bjacob/eigen/test/product.h: In function void product(const MatrixType) [with MatrixType = Eigen::Matrixfloat, 3, 2, 0]: /home/bjacob/eigen/test/product_small.cpp:31:5: instantiated from here /home/bjacob/eigen/test/product.h:45:60: internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9822 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #9 from jacob dot benoit dot 1 at gmail dot com 2009-12-11 17:10 --- I also confirm that I still have the ICE with the .ii file attached to this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #10 from hjl dot tools at gmail dot com 2009-12-11 17:24 --- Confirmed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug bootstrap/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-12-11 17:25 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap --- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:20 --- Is this still an issue? Yes, the problem still exists on alpha-dec-osf4.0f as of 20091210. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug target/42263] Wrong code bugs in SMP support
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-11 17:37 --- Subject: Bug 42263 Author: ramana Date: Fri Dec 11 17:37:34 2009 New Revision: 155171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155171 Log: 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/42263 2009-08-11 Andrew Haley a...@redhat.com * config/arm/arm.c (arm_init_libfuncs): Add __sync_synchronize. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug target/42263] Wrong code bugs in SMP support
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-11 17:45 --- Subject: Bug 42263 Author: ramana Date: Fri Dec 11 17:45:32 2009 New Revision: 155172 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155172 Log: 2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/42263 Backport from mainline 2009-12-03 Richard Earnshaw rearn...@arm.com * arm/linux-atomic.c (SYNC_LOCK_RELEASE): Place memory barrier before the lock release. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/linux-atomic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug target/42263] Wrong code bugs in SMP support
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-11 17:46 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code [4.4 only]
--- Comment #12 from ramana at gcc dot gnu dot org 2009-12-11 17:46 --- Fixed . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug libstdc++/22634] [DR 539] partial_sum is too constrained
--- Comment #20 from paolo at gcc dot gnu dot org 2009-12-11 17:55 --- Subject: Bug 22634 Author: paolo Date: Fri Dec 11 17:54:37 2009 New Revision: 155173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155173 Log: 2009-12-11 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/22634, DR 539 [Ready] * include/bits/stl_numeric.h (adjacent_difference): Use std::move at the end of the loop body, per the Ready resolution. * include/std/numeric: Do not include unnecessarily cstddef. * doc/xml/manual/intro.xml: Add an entry for DR 539. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/stl_numeric.h trunk/libstdc++-v3/include/std/numeric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #13 from ro at gcc dot gnu dot org 2009-12-11 17:55 --- Mine, fix in progress. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-29 16:34:25 |2009-12-11 17:55:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug libstdc++/22634] [DR 539] partial_sum is too constrained
--- Comment #21 from paolo dot carlini at oracle dot com 2009-12-11 17:56 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug lto/41657] FAIL: gcc.c-torture/execute/builtins/memmove-2.c compilation, -O2 -fwhopr
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-11 18:00 --- Subject: Bug 41657 Author: rguenth Date: Fri Dec 11 18:00:24 2009 New Revision: 155174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155174 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/41658 PR lto/41657 * lto-streamer-out.c (write_global_stream): Do not make decls weak but resort to TREE_ASM_WRITTEN to avoid multiple definitions. Make sure to mark all decls that we have written. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41657
[Bug lto/41658] Execution testsuite fails with -O2 -fwhopr
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-11 18:00 --- Subject: Bug 41658 Author: rguenth Date: Fri Dec 11 18:00:24 2009 New Revision: 155174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155174 Log: 2009-12-11 Richard Guenther rguent...@suse.de PR lto/41658 PR lto/41657 * lto-streamer-out.c (write_global_stream): Do not make decls weak but resort to TREE_ASM_WRITTEN to avoid multiple definitions. Make sure to mark all decls that we have written. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41658
[Bug lto/41658] Execution testsuite fails with -O2 -fwhopr
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-11 18:00 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41658
[Bug lto/41657] FAIL: gcc.c-torture/execute/builtins/memmove-2.c compilation, -O2 -fwhopr
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-11 18:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41657
[Bug c++/42352] New: -std=c++0x reference binding problem
Platform: Fedora release 12 (Constantine) Linux cage.lbl.gov 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux URL: svn://gcc.gnu.org/svn/gcc/trunk Revision: 150327 or higher gcc version 4.5.0 20090801 (experimental) (GCC) I'll attach a reproducer. g++ -c -std=c++0x list_sort_bind.cpp ... include/c++/4.5.0/bits/list.tcc:392:3: error: cannot bind 'std::listint' lvalue to 'std::listint' ... It works without -std=c++0x. svn rev. 150326 works, 150327 does not. The critical svn revision was: % svn log -v -c150327 r150327 | jason | 2009-07-31 19:26:42 -0700 (Fri, 31 Jul 2009) | 16 lines Changed paths: M /trunk/gcc/cp/ChangeLog M /trunk/gcc/cp/call.c M /trunk/gcc/cp/cp-tree.h M /trunk/gcc/cp/typeck.c M /trunk/gcc/testsuite/ChangeLog M /trunk/gcc/testsuite/g++.dg/cpp0x/initlist22.C M /trunk/gcc/testsuite/g++.dg/cpp0x/named.C M /trunk/gcc/testsuite/g++.dg/cpp0x/overload.C A /trunk/gcc/testsuite/g++.dg/cpp0x/overloadn.C (from /trunk/gcc/testsuite/g++.dg/cpp0x/overload.C:150326) A /trunk/gcc/testsuite/g++.dg/cpp0x/rv-cast.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv1n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv1p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv2n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv2p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv3n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv3p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv4n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv4p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv5n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv5p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv6n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv6p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv7n.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv7p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/rv8p.C M /trunk/gcc/testsuite/g++.dg/cpp0x/template_deduction.C M /trunk/gcc/testsuite/g++.dg/cpp0x/unnamed_refs.C M /trunk/libstdc++-v3/ChangeLog M /trunk/libstdc++-v3/include/bits/move.h M /trunk/libstdc++-v3/include/std/istream M /trunk/libstdc++-v3/include/std/ostream A /trunk/libstdc++-v3/testsuite/27_io/rvalue_streams.cc * call.c (convert_class_to_reference): Binding an lvalue to an rvalue reference is bad. If the user-defined conversion is bad, set bad_p before merging conversions. (maybe_handle_ref_bind): Don't push down bad_p. (reference_binding): Binding an lvalue to an rvalue reference is bad. (convert_like_real): Give a helpful error about binding lvalue to rvalue reference. (reference_related_p): No longer static. * typeck.c (build_typed_address): New. (build_static_cast_1): Add static_cast from lvalue to . * cp-tree.h: Adjust. * include/bits/move.h (forward): Implement as in N2835. (move): Implement as in N2831. * include/std/istream (rvalue stream operator): New. * include/std/ostream (rvalue stream operator): New. -- Summary: -std=c++0x reference binding problem Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #1 from rwgk at yahoo dot com 2009-12-11 18:05 --- Created an attachment (id=19277) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19277action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug target/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-11 18:10 --- Needed an update to a newer version of binutils. Invalid. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug target/41482] ICE in libgfortran arm thumb multilib compile
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-11 18:11 --- arm-elf is in maintenance only mode. Marking it as P4 - -- ramana at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41482
[Bug target/36697] SIGSEGV on program exit with gcc 4.3.1
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-11 18:15 --- No feedback in more than 6 months . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36697
[Bug target/37386] Interrupt service routine for arm target corrupts program counter
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-11 18:16 --- Fixed with 4.3.2 apparently. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37386
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-11 18:17 --- The std::, c++0x, version, is in flux. If you want the old behavior, just use std::tr1::bind for now, and do not expect and C++0x-conforming behavior. Really, no point in keeping open issues vs ongoing C++0x work. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug libgcj/36658] Building gcj for arm linux from trunk (gcc 4.4.0): libjava/gcj/array.h:24: internal compiler error: verify_gimple failed
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-11 18:19 --- No feedback in over a year and don't have more information . Hence Suspended. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36658
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #10 from ramana at gcc dot gnu dot org 2009-12-11 18:21 --- No feedback in over 6 months and appears to work fine in later versions of the tools. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-11 18:22 --- :) Sorry, this issue has nothing to do with std::bind (ansd std::tr1::bind) of course. This is actually about list::splcie and list::merge, which indeed are still in flux in the WP, see DR 1133, or: http://gcc.gnu.org/ml/libstdc++/2009-12/msg00011.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug target/35586] seg fault when compiling liboil 0.3.13, file conv_c.c
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-11 18:23 --- No feedback in over 6 months. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35586
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #6 from ramana at gcc dot gnu dot org 2009-12-11 18:27 --- As it could not be reproduced and a later comment indicates it works for 4.4.0. Resolved as INVALID. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-12-11 18:37 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00625.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #7 from rmansfield at qnx dot com 2009-12-11 18:38 --- The PR valid and it is still reproducible on the 4.3 branch and AFAIK the 4.3 branch is still open. A resolution of WONTFIX makes sense, but INVALID doesnt.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug c++/42352] -std=c++0x reference binding problem
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-11 18:43 --- Bah, we can use some std::move(s) in the splice and merge calls used by sort, and solve this. We'll be reverted as unnecessary when DR 1133 will be resolved, but maybe can make people more happy for the time being... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug c++/42352] -std=c++0x reference binding problem
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-11 18:43:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
[Bug fortran/40290] Spurious warning on REAL*COMPLEX with -Wconversion
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-11 18:56 --- Using -O3 -fno-signed-zeros (the latter being set by -ffast-math) gets rid of all the additional computations and results in bb 2: D.1504_2 = *a_1(D); D.1514_10 = REALPART_EXPR *b_4(D); D.1515_11 = IMAGPART_EXPR *b_4(D); D.1516_12 = D.1504_2 * D.1514_10; D.1517_13 = D.1504_2 * D.1515_11; __result_op.0_6 = COMPLEX_EXPR D.1516_12, D.1517_13; return __result_op.0_6; With the patch below, the warning would be disabled. However is this warning a feature (then keep it), or an artefact of an implementation detail (then remove it)? Index: expr.c === --- expr.c (revision 155148) +++ expr.c (working copy) @@ -720,9 +720,9 @@ gfc_type_convert_binary (gfc_expr *e) else e-ts.kind = op2-ts.kind; if (op1-ts.type != BT_COMPLEX || op1-ts.kind != e-ts.kind) -gfc_convert_type (e-value.op.op1, e-ts, 2); +gfc_convert_type_warn (e-value.op.op1, e-ts, 2, 0); if (op2-ts.type != BT_COMPLEX || op2-ts.kind != e-ts.kind) -gfc_convert_type (e-value.op.op2, e-ts, 2); +gfc_convert_type_warn (e-value.op.op2, e-ts, 2, 0); done: return; -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Keywords|missed-optimization | Known to fail|4.5.0 | Summary|Bogus conversion of |Spurious warning on |REAL*COMPLEX to |REAL*COMPLEX with - |COMPLEX*COMPLEX |Wconversion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40290
