Re: [PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
2012/1/13 Georg-Johann Lay :
> Denis Chertykov wrote:
>
>> Committed
>>
>> Denis
>
>
> Consider code prom PR51374
>
> void __vector_18 (void)
> {
> extern char slot;
> unsigned char status = (*(volatile unsigned char*) 0x2B);
> unsigned char data = (*(volatile unsigned char*) 0x2C);
>
> if (status & 0x10)
> slot = 0;
> }
>
> the code with -Os -S -dp sets up a frame pointer which is not needed and
> should
> not be there:
>
> __vector_18:
> push r28 ; 28 pushqi1/1 [length = 1]
> push r29 ; 29 pushqi1/1 [length = 1]
> in r28,__SP_L__ ; 30 *movhi/8 [length = 2]
> in r29,__SP_H__
> /* prologue: function */
> /* frame size = 0 */
> /* stack size = 2 */
> .L__stack_usage = 2
> in r24,0xc ; 8 movqi_insn/4 [length = 1]
> sbis 0xb,4 ; 11 *sbix_branch [length = 2]
> rjmp .L1
> sts slot,__zero_reg__ ; 13 movqi_insn/3 [length = 2]
> .L1:
> /* epilogue start */
> pop r29 ; 33 popqi [length = 1]
> pop r28 ; 34 popqi [length = 1]
> ret ; 35 return_from_epilogue [length = 1]
>
> This happens even for empty function.
Oops.
Something wrong happened, probably I committed a wrong untested patch.
It must be reverted.
Denis.
Re: [C++ Patch] PR 51225
On 01/13/2012 03:57 PM, Paolo Carlini wrote: Anyway, the reason we are not tsubst-ing such trees - eg, a CAST_EXPR on a single element TREE_LIST as argument, with error_mark_node as value - is that potential_constant_expression is false in fold_non_dependent_expr_sfinae, thus tsubst_copy_and_build is not called at all. We also shouldn't call cxx_eval_constant_expression if potential_constant_expression is false. Jason
RFA: PATCHes to vec.c and convert.c for c++/14179 (excessive memory consumption with array initializer)
While looking at the -fmem-stats results for this testcase, I noticed
about 500MB of overhead coming from the VEC_safe_push in
cp_lexer_new_main. This is happening because when we allocate space for
a vector, the allocator pads it out some, and that space ends up lost.
The first patch changes the vector code to ask the gc allocator how much
space it's really going to get, and adjust the number of slots to fill
that space. This reduces the VM footprint of the compiler for the
testcase from 1704 MB to 1162 MB, an almost 32% reduction.
The second patch is derived from Jan's patch of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245#c42
and further reduces the VM footprint to 967 MB, not quite back to the
2.95 level of 717 MB, but pretty close.
Tested x86_64-pc-linux-gnu. Are one or both of these OK for trunk?
commit 75f153fdd2166feeaa9fcc982951537c7c1cb4a7
Author: Jason Merrill
Date: Fri Jan 13 17:53:50 2012 -0500
PR c++/14179
* vec.c (vec_gc_o_reserve_1): Use ggc_round_alloc_size.
diff --git a/gcc/vec.c b/gcc/vec.c
index c1d0034..783a3cf 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -221,6 +221,7 @@ vec_gc_o_reserve_1 (void *vec, int reserve, size_t vec_offset, size_t elt_size,
{
struct vec_prefix *pfx = (struct vec_prefix *) vec;
unsigned alloc = calculate_allocation (pfx, reserve, exact);
+ size_t size;
if (!alloc)
{
@@ -229,7 +230,17 @@ vec_gc_o_reserve_1 (void *vec, int reserve, size_t vec_offset, size_t elt_size,
return NULL;
}
- vec = ggc_realloc_stat (vec, vec_offset + alloc * elt_size PASS_MEM_STAT);
+ /* Calculate the amount of space we want. */
+ size = vec_offset + alloc * elt_size;
+ /* Ask the allocator how much space it will really give us. */
+ size = ggc_round_alloc_size (size);
+ /* Adjust the number of slots accordingly. */
+ alloc = (size - vec_offset) / elt_size;
+ /* And finally, recalculate the amount of space we ask for. */
+ size = vec_offset + alloc * elt_size;
+
+ vec = ggc_realloc_stat (vec, size PASS_MEM_STAT);
+
((struct vec_prefix *)vec)->alloc = alloc;
if (!pfx)
((struct vec_prefix *)vec)->num = 0;
commit a18a514aa781b65048e69330564197b0692978aa
Author: Jason Merrill
Date: Fri Jan 13 17:54:44 2012 -0500
PR c/12245
PR c++/14179
* convert.c (convert_to_integer): Use fold_convert for
converting an INTEGER_CST to integer type.
diff --git a/gcc/convert.c b/gcc/convert.c
index f04b204..dbe2c7e 100644
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -860,6 +860,10 @@ convert_to_integer (tree type, tree expr)
break;
}
+ /* When parsing long initializers, we might end up with a lot of casts.
+ Shortcut this. */
+ if (TREE_CODE (expr) == INTEGER_CST)
+ return fold_convert (type, expr);
return build1 (CONVERT_EXPR, type, expr);
case REAL_TYPE:
Re: [PATCH] PR debug/45682 - wrong struct DIE nesting with -fdebug-types-section
Here's the final patch, with testcase. Bootstrapped and tested on
x86_64 with no regressions.
I'm not sure of the rules here -- since this patch was in process
before Stage 3 closed, is it OK for 4.7? Or do I need to hold this
until Stage 1 opens for 4.8?
-cary
gcc/ChangeLog:
PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary. Update caller.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller. Place skeleton DIE under parent DIE of original declaration.
gcc/testsuite/ChangeLog:
PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f9f4295..4f6bcad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3302,11 +3302,12 @@ static int should_move_die_to_comdat (dw_die_ref);
static dw_die_ref clone_as_declaration (dw_die_ref);
static dw_die_ref clone_die (dw_die_ref);
static dw_die_ref clone_tree (dw_die_ref);
-static void copy_declaration_context (dw_die_ref, dw_die_ref);
+static dw_die_ref copy_declaration_context (dw_die_ref, dw_die_ref);
static void generate_skeleton_ancestor_tree (skeleton_chain_node *);
static void generate_skeleton_bottom_up (skeleton_chain_node *);
static dw_die_ref generate_skeleton (dw_die_ref);
static dw_die_ref remove_child_or_replace_with_skeleton (dw_die_ref,
+ dw_die_ref,
dw_die_ref);
static void break_out_comdat_types (dw_die_ref);
static dw_die_ref copy_ancestor_tree (dw_die_ref, dw_die_ref, htab_t);
@@ -7075,11 +7076,12 @@ clone_as_declaration (dw_die_ref die)
AT_specification attribute, it also includes attributes and children
attached to the specification. */
-static void
+static dw_die_ref
copy_declaration_context (dw_die_ref unit, dw_die_ref die)
{
dw_die_ref decl;
dw_die_ref new_decl;
+ dw_die_ref new_parent = NULL;
decl = get_AT_ref (die, DW_AT_specification);
if (decl == NULL)
@@ -7090,6 +7092,10 @@ copy_declaration_context (dw_die_ref unit,
dw_die_ref die)
dw_die_ref c;
dw_attr_ref a;
+ /* The original DIE will be changed to a declaration, and must
+ be moved to be a child of the original declaration DIE. */
+ new_parent = decl->die_parent;
+
/* Copy the type node pointer from the new DIE to the original
declaration DIE so we can forward references later. */
decl->die_id.die_type_node = die->die_id.die_type_node;
@@ -7118,6 +7124,8 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref die)
add_AT_specification (die, new_decl);
}
}
+
+ return new_parent;
}
/* Generate the skeleton ancestor tree for the given NODE, then clone
@@ -7201,7 +7209,7 @@ generate_skeleton (dw_die_ref die)
return node.new_die;
}
-/* Remove the DIE from its parent, possibly replacing it with a cloned
+/* Remove the CHILD DIE from its parent, possibly replacing it with a cloned
declaration. The original DIE will be moved to a new compile unit
so that existing references to it follow it to the new location. If
any of the original DIE's descendants is a declaration, we need to
@@ -7209,7 +7217,8 @@ generate_skeleton (dw_die_ref die)
declarations back into the skeleton tree. */
static dw_die_ref
-remove_child_or_replace_with_skeleton (dw_die_ref child, dw_die_ref prev)
+remove_child_or_replace_with_skeleton (dw_die_ref child, dw_die_ref prev,
+ dw_die_ref new_parent)
{
dw_die_ref skeleton;
@@ -7219,7 +7228,16 @@ remove_child_or_replace_with_skeleton
(dw_die_ref child, dw_die_ref prev)
else
{
skeleton->die_id.die_type_node = child->die_id.die_type_node;
- replace_child (child, skeleton, prev);
+
+ /* If the original DIE was a specification, we need to put
+ the skeleton under the parent DIE of the declaration. */
+ if (new_parent != NULL)
+ {
+ remove_child_with_prev (child, prev);
+ add_child_die (new_parent, skeleton);
+ }
+ else
+ replace_child (child, skeleton, prev);
}
return skeleton;
@@ -7247,7 +7265,7 @@ break_out_comdat_types (dw_die_ref die)
next = (c == first ? NULL : c->die_sib);
if (should_move_die_to_comdat (c))
{
-dw_die_ref replacement;
+dw_die_ref replacement, new_parent;
comdat_type_node_ref type_node;
/* Create a new type unit DIE as the root for the new tree, and
@@ -7265,10 +7283,11 @@ break_out_comdat_types (dw_die_ref die)
/* Copy the declaration context, attributes, and children of the
declaration into the new compile unit DIE. */
- copy_declaration_context (unit, c);
+ new_parent = copy_declaration_context (unit, c);
/* Remove this DIE from the main CU. */
- replacement = remove_child
Re: Patch RFA: Fix for c++/50012
On 01/13/2012 05:48 PM, Ian Lance Taylor wrote: * typeck.c (enum_cast_to_uint): New static function. Shouldn't this be "enum_cast_to_int", since the promotion is to integer_type_node? OK with that change. Jason
[patch] libitm: Truncate undo log after rolling back.
When rolling back the undo log, the previous code restored the previous
data values but didn't actually truncate the undo log. So, on the next
restart of the transaction, we would be growing the undo log and
performing old undos again, leading to data corruption.
Committed to trunk as obvious.
commit bb61ffd92da2fcc421420c8d5fb155e8273e0a1e
Author: torvald
Date: Fri Jan 13 23:45:42 2012 +
libitm: Truncate undo log after rolling back.
libitm/
* local.cc (GTM::gtm_undolog::rollback): Truncate undo log after
rolling back.
* containers.h (GTM::vector::set_size): New.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@183173
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/libitm/containers.h b/libitm/containers.h
index 394b6f2..3690565 100644
--- a/libitm/containers.h
+++ b/libitm/containers.h
@@ -92,6 +92,7 @@ class vector
size_t size() const { return m_size; }
size_t capacity() const { return this->capacity; }
+ void set_size (size_t size) { m_size = size; }
void clear() { m_size = 0; }
iterator push() {
diff --git a/libitm/local.cc b/libitm/local.cc
index 5645a12..d0d96ce 100644
--- a/libitm/local.cc
+++ b/libitm/local.cc
@@ -61,6 +61,7 @@ gtm_undolog::rollback (gtm_thread* tx, size_t until_size)
if (likely(ptr > top || (uint8_t*)ptr + len <= bot))
__builtin_memcpy (ptr, &undolog[i], len);
}
+ undolog.set_size(until_size);
}
}
Re: [RFC, patch] libitm: Filter out undo writes that overlap with the libitm stack.
On Wed, 2012-01-11 at 08:09 +1100, Richard Henderson wrote:
> On 01/11/2012 12:43 AM, Torvald Riegel wrote:
> >> One could steal code from bohem-gc for this.
> >> See GC_get_stack_base in os_dep.c.
> >
> > Thanks for the pointer. I looked at this code, and it seems fairly
> > complex given the dependencies on OS/libc and OS/libc behavior. From a
> > maintenance point-of-view, does it make sense to copy that complexity
> > into libitm? boehm-gc is used in GCC, so perhaps that's not much of a
> > problem, however. I also looked at glibc's memcpy implementations, and
> > copying those plus a simple byte-wise copy for the generic case could be
> > also a fairly clean solution.
> > Also, is the license compatible with the GPL wrt. mixing sources?
>
> From the maintenance point of view, I do think it makes sense to copy.
> As for the license, I expect we'd want to copy into a separate file so
> that we can keep things vaguely separated.
>
> > What about keeping the patch/hack that I posted for now, creating a PR,
> > and looking at this again for another release?
>
> I suppose that's not unreasonable. Ok with...
>
> > +static inline void *
> > +mask_stack_bottom(gtm_thread *tx)
> > +{
> > + return (uint8_t*)__builtin_dwarf_cfa() - 128;
> > +}
>
> Not only can this not be inline, it must be out-of-line. Otherwise you're
> not including the stack frame of gtm_undolog::rollback much less memcpy. You
> could get this result inline if you specialized for the arch by looking at
> the hard stack pointer register, but __builtin_dwarf_cfa is at the wrong end
> of the stack.
Oops. Based on the previous code I thought it would return the bottom
end of the stack frame. Made this function noinline and moved it to
config/generic/tls.c.
>
> You might as well make the fudge factor a lot larger. Like 4-8k.
Opted for 256 because too large might prevents undos to more than
expected with tight stack space.
>
> > + if (likely(ptr > top || (uint8_t*)ptr + len <=bot))
>
> Missing space before "bot".
Committed with those changes as rev 183172. Created PR libitm/51855.
Re: [patch] Flag-controlled type conversions/promotions
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
> Hi there,
>
> please find attached the patch and the Changelog entry for our work on
> the fortran bug #48426.
>
> The attached patch implements the options
>
> -finteger-4-integer-8
> -freal-4-real-8
> -freal-4-real-10
> -freal-4-real-16
> -freal-8-real-4
> -freal-8-real-10
> -freal-8-real-16
>
> to implement a variety of automatic type promotions. (This is particularly
> helpful if one wants to quickly check whether a certain code has a bug
> limiting
> its precision away from full machine accuracy.)
>
I plan to commit the attached patch this weekend.
2011-11-09 Zydrunas Gimbutas
Andreas Kloeckner
Steven G. Kargl
PR fortran/48426
* gfortran.h (gfc_option_t): Add members flag_*_kind to store kind.
* lang.opt: Add options -freal-4-real-8, -freal-4-real-10,
-freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16
and -finteger-4-integer-8. User-desired type conversion information.
* decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions
in declaration parsing.
* trans-types.c (gfc_init_kinds): User-specified type conversion
checked for current backend.
* primary.c (match_integer_constant,match_real_constant): Implement
type conversion in constant parsing.
* options.c (gfc_init_options,gfc_handle_option): Translate input
options to flags in internal options data structure.
* invoke.texi: Document new options. Re-order options in Options
summary section.
--
Steve
Index: decl.c
===
--- decl.c (revision 183169)
+++ decl.c (working copy)
@@ -1572,7 +1572,8 @@ build_struct (const char *name, gfc_char
/* Should this ever get more complicated, combine with similar section
in add_init_expr_to_sym into a separate function. */
- if (c->ts.type == BT_CHARACTER && !c->attr.pointer && c->initializer && c->ts.u.cl
+ if (c->ts.type == BT_CHARACTER && !c->attr.pointer && c->initializer
+ && c->ts.u.cl
&& c->ts.u.cl->length && c->ts.u.cl->length->expr_type == EXPR_CONSTANT)
{
int len;
@@ -2101,6 +2102,33 @@ gfc_match_old_kind_spec (gfc_typespec *t
return MATCH_ERROR;
}
ts->kind /= 2;
+
+}
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
}
if (gfc_validate_kind (ts->type, ts->kind, true) < 0)
@@ -2246,7 +2274,33 @@ kind_expr:
if(m == MATCH_ERROR)
gfc_current_locus = where;
-
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
+}
+
/* Return what we know from the test(s). */
return m;
Index: trans-types.c
===
--- trans-types.c (revision 183169)
+++ trans-types.c (working copy)
@@ -362,7 +362,7 @@ gfc_init_kinds (void)
unsigned int mode;
int i_index, r_index, kind;
bool saw_i4 = false, saw_i8 = false;
- bool saw_r4 = false, saw_r8 = false, saw_r16 = false;
+ bool saw_r4 = false, saw_r8 = false, saw_r10 = false, saw_r16 = false;
for (i_index = 0, mode = MIN_MODE_INT; mode <= MAX_MODE_INT; mode++)
{
@@ -456,6 +456,8 @@ gfc_init_kinds (void)
saw_r4 = true;
if (kind == 8)
saw_r8 = true;
+ if (kind == 10)
+ saw_r10 = true;
if (kind == 16)
saw_r16 = true;
@@ -482,23 +484,31 @@ gfc_init_kinds (void)
r_index += 1;
}
- /* Choose the default integer kind. We choose 4 unless the user
- directs us otherwise. */
+ /* Choose the default integer kind. We choose 4 unless the user directs us
+ otherwise. Even if the user specified that the default integer kind is 8,
+ the numeric storage size is not 64 bits. In this case, a warning will be
+ issued when NUMERIC_STORAGE_SIZE is used. Set NUME
Re: [Patch libgo]: Move Iopl and Ioperm to 368/amd64 specific libcall_linux_*.go files.
David Daney writes:
> As discussed several months ago, libgo will not run on mips because it
> references the x86 specific system calls iopl() and ioperm(). These
> system calls do not exist in mips*-linux, so we move them to new
> 368/amd64 specific libcall_linux_*.go files.
>
> The attached patch was tested on x86_64-linux-gnu with no libgo
> failures. There are still some other problems with mips*-linux, but
> this makes forward progress.
>
> It is unclear what kind of change log is required, so I do not supply one.
>
> Cavium, Inc. should now have a corporate contributor license agreement
> on file, so I think you can commit this upstream if acceptable.
Thanks for the patch, and sorry for the delay. The copyright issues are
sorted. The syntax has changed slightly (int -> error), and the calls
are also supported on Alpha. Bootstrapped on x86_64-unknown-linux-gnu.
Committed to mainline as follows.
Ian
diff -r 69eedc90c707 libgo/go/syscall/libcall_linux.go
--- a/libgo/go/syscall/libcall_linux.go Fri Jan 13 15:22:41 2012 -0800
+++ b/libgo/go/syscall/libcall_linux.go Fri Jan 13 15:33:45 2012 -0800
@@ -207,12 +207,6 @@
// //sysnb Gettid() (tid int)
// //gettid() Pid_t
-//sys Ioperm(from int, num int, on int) (err error)
-//ioperm(from _C_long, num _C_long, on int) int
-
-//sys Iopl(level int) (err error)
-//iopl(level int) int
-
// FIXME: mksysinfo linux_dirent
//Or just abandon this function.
// //sys Getdents(fd int, buf []byte) (n int, err error)
@@ -278,19 +272,19 @@
func Splice(rfd int, roff *int64, wfd int, woff *int64, len int, flags int) (n int64, err error) {
var lroff _loff_t
var plroff *_loff_t
- if (roff != nil) {
+ if roff != nil {
plroff = &lroff
}
var lwoff _loff_t
var plwoff *_loff_t
- if (woff != nil) {
+ if woff != nil {
plwoff = &lwoff
}
n, err = splice(rfd, plroff, wfd, plwoff, len, flags)
- if (roff != nil) {
+ if roff != nil {
*roff = int64(lroff)
}
- if (woff != nil) {
+ if woff != nil {
*woff = int64(lwoff)
}
return
diff -r 69eedc90c707 libgo/go/syscall/libcall_linux_386.go
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/libgo/go/syscall/libcall_linux_386.go Fri Jan 13 15:33:45 2012 -0800
@@ -0,0 +1,13 @@
+// Copyright 2012 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// GNU/Linux library calls 386 specific.
+
+package syscall
+
+//sys Ioperm(from int, num int, on int) (err error)
+//ioperm(from _C_long, num _C_long, on int) int
+
+//sys Iopl(level int) (err error)
+//iopl(level int) int
diff -r 69eedc90c707 libgo/go/syscall/libcall_linux_alpha.go
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/libgo/go/syscall/libcall_linux_alpha.go Fri Jan 13 15:33:45 2012 -0800
@@ -0,0 +1,13 @@
+// Copyright 2012 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// GNU/Linux library calls Alpha specific.
+
+package syscall
+
+//sys Ioperm(from int, num int, on int) (err error)
+//ioperm(from _C_long, num _C_long, on int) int
+
+//sys Iopl(level int) (err error)
+//iopl(level int) int
diff -r 69eedc90c707 libgo/go/syscall/libcall_linux_amd64.go
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/libgo/go/syscall/libcall_linux_amd64.go Fri Jan 13 15:33:45 2012 -0800
@@ -0,0 +1,13 @@
+// Copyright 2012 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// GNU/Linux library calls amd64 specific.
+
+package syscall
+
+//sys Ioperm(from int, num int, on int) (err error)
+//ioperm(from _C_long, num _C_long, on int) int
+
+//sys Iopl(level int) (err error)
+//iopl(level int) int
[Cilkplus] Updated Copyright year in all Cilkplus specific files
Hello Everyone, I just updated the copyright year in all the cilkplus specific files in the Cilkplus branch. I also corrected a wordwrap problem in one of the files. Here is the patch for what I updated. Thanks, Balaji V. Iyer. Index: pragma_simd.c === --- pragma_simd.c (revision 183162) +++ pragma_simd.c (working copy) @@ -1,7 +1,7 @@ /* This file is part of the Intel(R) Cilk(TM) Plus support - This file contains routines to handle PRAGMA SIMD assignments by the - vectorizer. - Copyright (C) 2011 Free Software Foundation, Inc. + This file contains routines to handle PRAGMA SIMD + assignments by the vectorizer. + Copyright (C) 2011, 2012 Free Software Foundation, Inc. Contributed by Balaji V. Iyer , Intel Corporation Index: cp/cilk.c === --- cp/cilk.c (revision 183162) +++ cp/cilk.c (working copy) @@ -1,5 +1,5 @@ /* C++ Functions to handle Intel(R) Cilk(TM) Plus Specific functions. - Copyright (C) 2011 Free Software Foundation, Inc. + Copyright (C) 2011, 2012 Free Software Foundation, Inc. Contributed by Balaji V. Iyer , Intel Corporation. Index: cilk.c === --- cilk.c (revision 183162) +++ cilk.c (working copy) @@ -1,6 +1,6 @@ /* This file is part of the Intel(R) Cilk(TM) Plus support This file contains the CilkPlus Intrinsics - Copyright (C) 2011 Free Software Foundation, Inc. + Copyright (C) 2011, 2012 Free Software Foundation, Inc. Contributed by Balaji V. Iyer , Intel Corporation Index: cilk.h === --- cilk.h (revision 183162) +++ cilk.h (working copy) @@ -1,6 +1,6 @@ /* This file is part of the Intel(R) Cilk(TM) Plus support This file contains Cilk Support files. - Copyright (C) 2011 Free Software Foundation, Inc. + Copyright (C) 2011, 2012 Free Software Foundation, Inc. Contributed by Balaji V. Iyer , Intel Corporation Index: cilk-spawn.c === --- cilk-spawn.c (revision 183162) +++ cilk-spawn.c (working copy) @@ -1,6 +1,6 @@ /* This file is part of the Intel(R) Cilk(TM) Plus support This file contains cilk functions for C language support - Copyright (C) 2011 Free Software Foundation, Inc. + Copyright (C) 2011, 2012 Free Software Foundation, Inc. Contributed by Balaji V. Iyer , Intel Corporation
Re: libgo patch committed: Update to weekly.2011-12-22
Uros Bizjak writes:
> On Fri, Jan 13, 2012 at 7:00 PM, Ian Lance Taylor wrote:
>
>> Thanks for the report, but this is surprising. Doesn't Alpha GNU/Linux
>> define TIOCGWINSZ in /usr/include/asm-generic/ioctls.h? And isn't that
>> file #include'd, indirectly, by ?
>>
>> If not, does Alpha GNU/Linux define TIOCGWINSZ at all, and how does it
>> define it? I thought TIOCGWINSZ was common, and I'm particularly
>> surprised to not find it on a GNU/Linux system.
>
> This is the same problem with -fdump-go-spec we discussed a couple of
> months ago [1]. In short, alpha linux doesn't just include
> with hardcoded numbers in asm/ioctls.h, but
> builds ioctl arguments as shown in [1]. Probably, this is the right
> way ...
Oh yeah.
I think I've worked out a way to handle this kind of thing. With luck
this patch will fix the problem. Bootstrapped on
x86_64-unknown-linux-gnu, although that doesn't really test it properly.
Committed to mainline. Please let me know if this helps.
Thanks for reporting the problem.
Ian
diff -r ade619795842 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Fri Jan 13 15:02:22 2012 -0800
+++ b/libgo/mksysinfo.sh Fri Jan 13 15:15:32 2012 -0800
@@ -89,6 +89,15 @@
#if defined(HAVE_NET_IF_H)
#include
#endif
+
+/* Constants that may only be defined as expressions on some systems,
+ expressions too complex for -fdump-go-spec to handle. These are
+ handled specially below. */
+enum {
+#ifdef TIOCGWINSZ
+ TIOCGWINSZ_val = TIOCGWINSZ,
+#endif
+};
EOF
${CC} -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
@@ -524,7 +533,14 @@
# The ioctl flags for the controlling TTY.
grep '^const _TIOC' gen-sysinfo.go | \
+grep -v '_val =' | \
sed -e 's/^\(const \)_\(TIOC[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+# We need TIOCGWINSZ.
+if ! grep '^const TIOCGWINSZ' ${OUT} >/dev/null 2>&1; then
+ if grep '^const _TIOCGWINSZ_val' ${OUT} >/dev/null 2>&1; then
+echo 'const TIOCGWINSZ = TIOCGWINSZ_val' >> ${OUT}
+ fi
+fi
# The ioctl flags for terminal control
grep '^const _TC[GS]ET' gen-sysinfo.go | \
Re: libgo patch committed: Update to weekly.2011-12-22
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> I have committed a patch to libgo to update it to the weekly.2011-12-22
>> release. As usual I am not including all the changes here, only the
>> ones to files which are specific to gccgo. Bootstrapped and ran Go
>> testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
>
> This also broke bootstrap on x86_64-unknown-linux-gnu (CentOS 5.5):
>
> /vol/gcc/src/hg/trunk/local/libgo/go/net/fd_linux.go:40:46: error: reference
> to undefined identifier 'syscall.EPOLL_CLOEXEC'
Thanks. Fixed like so. Bootstrapped on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 5623a1911326 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Thu Jan 12 21:00:14 2012 -0800
+++ b/libgo/mksysinfo.sh Fri Jan 13 15:01:55 2012 -0800
@@ -193,10 +193,13 @@
# epoll constants.
grep '^const _EPOLL' gen-sysinfo.go |
sed -e 's/^\(const \)_\(EPOLL[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
-# Make sure EPOLLRDHUP is defined.
+# Make sure EPOLLRDHUP and EPOLL_CLOEXEC are defined.
if ! grep '^const EPOLLRDHUP' ${OUT} >/dev/null 2>&1; then
echo "const EPOLLRDHUP = 0x2000" >> ${OUT}
fi
+if ! grep '^const EPOLL_CLOEXEC' ${OUT} >/dev/null 2>&1; then
+ echo "const EPOLL_CLOEXEC = 0200" >> ${OUT}
+fi
# Ptrace constants.
grep '^const _PTRACE' gen-sysinfo.go |
Patch RFA: Fix for c++/50012
PR c++/50012 shows a case where we do not issue a -Wsign-compare warning
when we should. I introduced this problem here:
2009-06-25 Ian Lance Taylor
* call.c (avoid_sign_compare_warnings): New static function.
(build_new_op): Call it.
* typeck.c (cp_build_binary_op): Don't call warn_sign_compare if
TREE_NO_WARNING is set on either operand.
This patch fixes the problem by avoiding the overload of the
TREE_NO_WARNING bit.
Making this change required adjusting TYPE_QUALS and
TYPE_QUALS_NO_ADDR_SPACE. These are expressions involving enum values.
In C++ these expressions wound up promoted to unsigned int, but the
callers, at least the ones which do comparisons, expect signed int. For
this patch I added an explicit cast to int to the macros, since that is
what the callers expect.
Bootstrapped and ran gcc testsuite on x86_64-unknown-linux-gnu for all
languages. I bootstrapped with and without
--disable-build-poststage1-with-cxx.
OK for mainline?
Ian
gcc/ChangeLog:
2012-01-13 Ian Lance Taylor
PR c++/50012
* tree.h (TYPE_QUALS): Add cast to int.
(TYPE_QUALS_NO_ADDR_SPACE): Likewise.
gcc/cp/ChangeLog:
2012-01-13 Ian Lance Taylor
PR c++/50012
* typeck.c (enum_cast_to_uint): New static function.
(cp_build_binary_op): When handling warn_sign_compare, don't test
for TREE_NO_WARNING. Do call enum_cast_to_uint.
* call.c (avoid_sign_compare_warnings): Remove static function.
(build_new_op_1): Don't call avoid_sign_compare_warnings.
gcc/testsuite/ChangeLog:
2012-01-13 Ian Lance Taylor
PR c++/50012
* g++.dg/warn/Wsign-compare-4.C: New.
Index: tree.h
===
--- tree.h (revision 183165)
+++ tree.h (working copy)
@@ -1,6 +1,6 @@
/* Front-end tree definitions for GNU compiler.
Copyright (C) 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
- 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -2298,16 +2298,16 @@ enum cv_qualifier
/* The set of type qualifiers for this type. */
#define TYPE_QUALS(NODE) \
- ((TYPE_READONLY (NODE) * TYPE_QUAL_CONST) \
- | (TYPE_VOLATILE (NODE) * TYPE_QUAL_VOLATILE) \
- | (TYPE_RESTRICT (NODE) * TYPE_QUAL_RESTRICT) \
- | (ENCODE_QUAL_ADDR_SPACE (TYPE_ADDR_SPACE (NODE
+ ((int) ((TYPE_READONLY (NODE) * TYPE_QUAL_CONST) \
+ | (TYPE_VOLATILE (NODE) * TYPE_QUAL_VOLATILE) \
+ | (TYPE_RESTRICT (NODE) * TYPE_QUAL_RESTRICT) \
+ | (ENCODE_QUAL_ADDR_SPACE (TYPE_ADDR_SPACE (NODE)
/* The same as TYPE_QUALS without the address space qualifications. */
#define TYPE_QUALS_NO_ADDR_SPACE(NODE)\
- ((TYPE_READONLY (NODE) * TYPE_QUAL_CONST) \
- | (TYPE_VOLATILE (NODE) * TYPE_QUAL_VOLATILE) \
- | (TYPE_RESTRICT (NODE) * TYPE_QUAL_RESTRICT))
+ ((int) ((TYPE_READONLY (NODE) * TYPE_QUAL_CONST) \
+ | (TYPE_VOLATILE (NODE) * TYPE_QUAL_VOLATILE) \
+ | (TYPE_RESTRICT (NODE) * TYPE_QUAL_RESTRICT)))
/* These flags are available for each language front end to use internally. */
#define TYPE_LANG_FLAG_0(NODE) (TYPE_CHECK (NODE)->type_common.lang_flag_0)
Index: testsuite/g++.dg/warn/Wsign-compare-4.C
===
--- testsuite/g++.dg/warn/Wsign-compare-4.C (revision 0)
+++ testsuite/g++.dg/warn/Wsign-compare-4.C (revision 0)
@@ -0,0 +1,12 @@
+//PR c++/50012
+// { dg-options "-Wsign-compare" }
+
+int foo(unsigned int *a, int b)
+{
+ return (*a) <= b; // { dg-warning "comparison between signed and unsigned" }
+}
+
+int bar(unsigned int *a, int b)
+{
+ return *a <= b; // { dg-warning "comparison between signed and unsigned" }
+}
Index: cp/typeck.c
===
--- cp/typeck.c (revision 183165)
+++ cp/typeck.c (working copy)
@@ -1,6 +1,7 @@
/* Build expressions with type checking for C++ compiler.
Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
- 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
+ 2011, 2012
Free Software Foundation, Inc.
Hacked by Michael Tiemann (tiem...@cygnus.com)
@@ -3599,6 +3600,29 @@ build_x_array_ref (tree arg1, tree arg2,
return expr;
}
+/* Return whether OP is an expression of enum type cast to integer
+ type. In C++ even unsigned enum types are cast to signed integer
+ types. We do not want to issue warnings about comparisons between
+ signed and unsigned types when one of the types is an enum type.
+ Those warnings are always false positives in practice. */
+
+static bool
+enum_cast_to_uint (tree op)
+{
+ if (TREE_CODE (op) == NOP_EXPR
+ && TREE_TYPE (op) == integer_type_node
+ && TR
Patch committed: Update copyright year
I forgot to update the copyright year in the patch I just committed. This patch corrects that omission. I did not bother with a separate ChangeLog entry for this patch, since I think it is implicitly covered by the ChangeLog entry I just committed. Sorry for omitting this earlier. Ian Index: ipa-cp.c === --- ipa-cp.c (revision 183166) +++ ipa-cp.c (working copy) @@ -1,5 +1,5 @@ /* Interprocedural constant propagation - Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010, 2011 + Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc. Contributed by Razya Ladelsky and Martin Jambor
Patch committed: Add typecasts to avoid signed/unsigned warning
A patch I have developed for PR 50012 issues a warning for some code in
ipa-cp.c in which a variable of type int is compared to the return value
of VEC_length, which is unsigned int. This should logically require a
type cast, and actually I'm not sure why the warning is not issued
without my patch. In any case, this patch adds the required type
casts. Committed as obvious.
Ian
2012-01-13 Ian Lance Taylor
* ipa-cp.c (ipa_get_indirect_edge_target): Add typecasts when
comparing param_index to VEC_length result.
Index: ipa-cp.c
===
--- ipa-cp.c (revision 183165)
+++ ipa-cp.c (working copy)
@@ -1112,7 +1112,7 @@ ipa_get_indirect_edge_target (struct cgr
if (!ie->indirect_info->polymorphic)
{
- tree t = (VEC_length (tree, known_vals) > param_index
+ tree t = (VEC_length (tree, known_vals) > (unsigned int) param_index
? VEC_index (tree, known_vals, param_index) : NULL);
if (t &&
TREE_CODE (t) == ADDR_EXPR
@@ -1127,7 +1127,8 @@ ipa_get_indirect_edge_target (struct cgr
otr_type = ie->indirect_info->otr_type;
t = VEC_index (tree, known_vals, param_index);
- if (!t && known_binfos && VEC_length (tree, known_binfos) > param_index)
+ if (!t && known_binfos
+ && VEC_length (tree, known_binfos) > (unsigned int) param_index)
t = VEC_index (tree, known_binfos, param_index);
if (!t)
return NULL_TREE;
Re: useless_type_conversion_p vs pointer sizes
> That should not be necessary as there is a mode check below. Do you
> hit the issue only when the VOID_TYPE_P check is true? In that case
> simply delete it - it has become obsolete.
That seems to be happening, yes, but there are other checks
that might let differing modes through...
/* Changes in machine mode are never useless conversions unless we
deal with aggregate types in which case we defer to later checks. */
if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type)
&& !AGGREGATE_TYPE_P (inner_type))
return false;
Later,
else if (POINTER_TYPE_P (inner_type)
&& POINTER_TYPE_P (outer_type))
{
/* Do not lose casts to function pointer types. */
if ((TREE_CODE (TREE_TYPE (outer_type)) == FUNCTION_TYPE
|| TREE_CODE (TREE_TYPE (outer_type)) == METHOD_TYPE)
&& !(TREE_CODE (TREE_TYPE (inner_type)) == FUNCTION_TYPE
|| TREE_CODE (TREE_TYPE (inner_type)) == METHOD_TYPE))
return false;
/* We do not care for const qualification of the pointed-to types
as const qualification has no semantic value to the middle-end. */
/* Otherwise pointers/references are equivalent. */
return true;
}
So two different sized pointers to aggregate types will also have a problem?
I'm a little paranoid here because TPF uses different sized pointers a
*lot* so if we can't guarantee that the rest of the logic keeps the
conversion, I'd rather keep the explicit check.
Re: [PATCH] hashtable insert enhancement
Attached patch applied. 2012-01-13 François Dumont * include/bits/hashtable_policy.h (_Hash_node_base): New, use it as base class of ... (_Hash_node, _Hash_node): ... those. * include/bits/hashtable.h (_Hashtable): Replace _M_begin_bucket_index by _M_before_begin. Review implementation so that we do not need to look for previous non-empty bucket when inserting nodes. François On 01/13/2012 12:03 AM, Paolo Carlini wrote: On 01/09/2012 09:36 PM, François Dumont wrote: Same patch proposition as the previous one except that I have revisited the _M_rehash method that was still trying to keep nodes ordered by their bucket index. Please go ahead. Thanks, Paolo. Index: include/bits/hashtable.h === --- include/bits/hashtable.h (revision 183031) +++ include/bits/hashtable.h (working copy) @@ -93,13 +93,13 @@ // and unordered_multimap. /** * Here's _Hashtable data structure, each _Hashtable has: - * - _Bucket[] _M_buckets - * - size_type _M_bucket_count - * - size_type _M_begin_bucket_index - * - size_type _M_element_count + * - _Bucket[] _M_buckets + * - _Hash_node_base _M_before_begin + * - size_type _M_bucket_count + * - size_type _M_element_count * - * with _Bucket being _Node* and _Node: - * - _Node*_M_next + * with _Bucket being _Hash_node* and _Hash_node constaining: + * - _Hash_node* _M_next * - Tp_M_value * - size_t_M_code if cache_hash_code is true * @@ -107,36 +107,34 @@ * - std::forward_list<_Node> containing the elements * - std::vector::iterator> representing the buckets * - * The first non-empty bucket with index _M_begin_bucket_index contains the - * first container node which is also the first bucket node whereas other - * non-empty buckets contain the node before the first bucket node. This is so - * to implement something like a std::forward_list::erase_after on container - * erase calls. + * The non-empty buckets contain the node before the first bucket node. This + * design allow to implement something like a std::forward_list::insert_after + * on container insertion and std::forward_list::erase_after on container + * erase calls. _M_before_begin is equivalent to + * std::foward_list::before_begin. Empty buckets are containing nullptr. + * Note that one of the non-empty bucket contains &_M_before_begin which is + * not a derefenrenceable node so the node pointers in buckets shall never be + * derefenrenced, only its next node can be. * - * Access to the bucket last element require a check on the hash code to see - * if the node is still in the bucket. Such a design impose a quite efficient - * hash functor and is one of the reasons it is highly advise to set + * Walk through a bucket nodes require a check on the hash code to see if the + * node is still in the bucket. Such a design impose a quite efficient hash + * functor and is one of the reasons it is highly advise to set * __cache_hash_code to true. * * The container iterators are simply built from nodes. This way incrementing - * the iterator is perfectly efficient no matter how many empty buckets there - * are in the container. + * the iterator is perfectly efficient independent of how many empty buckets + * there are in the container. * * On insert we compute element hash code and thanks to it find the bucket - * index. If the element is the first one in the bucket we must find the - * previous non-empty bucket where the previous node rely. To keep this loop - * minimal it is important that the number of bucket is not too high compared - * to the number of elements. So the hash policy must be carefully design so - * that it computes a bucket count large enough to respect the user defined - * load factor but also not too large to limit impact on the insert operation. + * index. If the element must be inserted on an empty bucket we add it at the + * beginning of the singly linked list and make the bucket point to + * _M_before_begin. The bucket that used to point to _M_before_begin, if any, + * is updated to point to its new before begin node. * * On erase, the simple iterator design impose to use the hash functor to get * the index of the bucket to update. For this reason, when __cache_hash_code * is set to false, there is a static assertion that the hash functor cannot * throw. - * - * _M_begin_bucket_index is used to offer contant time access to the container - * begin iterator. */ template, _Cond>; + // When hash codes are not cached the hash functor shall not throw + // because it is used in methods (erase, swap...) that shall not throw. static_assert(__if_hash_code_not_cached<__detail::__is_noexcept_hash<_Key, _H1>>::value,
Re: [patch] Remove #include tree-mudflap.h from a few files
On Fri, 13 Jan 2012, Steven Bosscher wrote: > Hello, > > Nothing fancy, just remove an odd couple of #includes that are not necessary. > OK for trunk? OK with dependencies updated in Makefile.in. -- Joseph S. Myers jos...@codesourcery.com
[patch] Remove #include tree-mudflap.h from a few files
Hello, Nothing fancy, just remove an odd couple of #includes that are not necessary. OK for trunk? Ciao! Steven gcc/ * c-decl.c: Do not include tree-mudflap.h * tree-optimize.c: Likewise. cp/ * decl2.c: Do not include tree-mudflap.h * semantics.c: Likewise. gcc/ * c-decl.c: Do not include tree-mudflap.h * tree-optimize.c: Likewise. cp/ * decl2.c: Do not include tree-mudflap.h * semantics.c: Likewise. Index: c-decl.c === --- c-decl.c(revision 183161) +++ c-decl.c(working copy) @@ -50,7 +50,6 @@ along with GCC; see the file COPYING3. #include "c-family/c-pragma.h" #include "c-lang.h" #include "langhooks.h" -#include "tree-mudflap.h" #include "tree-iterator.h" #include "diagnostic-core.h" #include "tree-dump.h" Index: tree-optimize.c === --- tree-optimize.c (revision 183161) +++ tree-optimize.c (working copy) @@ -38,7 +38,6 @@ along with GCC; see the file COPYING3. #include "flags.h" #include "cgraph.h" #include "tree-inline.h" -#include "tree-mudflap.h" #include "tree-pass.h" #include "ggc.h" #include "cgraph.h" Index: cp/decl2.c === --- cp/decl2.c (revision 183161) +++ cp/decl2.c (working copy) @@ -43,7 +43,6 @@ along with GCC; see the file COPYING3. #include "target.h" #include "c-family/c-common.h" #include "c-family/c-objc.h" -#include "tree-mudflap.h" #include "cgraph.h" #include "tree-inline.h" #include "c-family/c-pragma.h" Index: cp/semantics.c === --- cp/semantics.c (revision 183161) +++ cp/semantics.c (working copy) @@ -33,7 +33,6 @@ along with GCC; see the file COPYING3. #include "c-family/c-common.h" #include "c-family/c-objc.h" #include "tree-inline.h" -#include "tree-mudflap.h" #include "intl.h" #include "toplev.h" #include "flags.h"
[Patch, fortran] PR 51808 Heap allocate binding labels
Hi, the attached patch changes the binding labels that are needed for bind(C) symbols to be heap allocated rather than, as currently, being fixed size arrays of size 127 (or 64 in module.c!?). There are two benefits of this: 1) For the vast majority of symbols which are not bind(C) symbols in a typical Fortran program, we save some memory. 2) For bind(C) symbols with a non-default binding label, that is bind(C, name="foo"), the label can be arbitrary long, subject to heap memory limitations obviously. While Fortran limits names to be at most 63 characters, the binding label is not a Fortran name and the Fortran standard places no limit on the length of it. Similarly, C99 merely requires that the implementation must support identifiers containing at least 31 characters, but allows implementations to support arbitrarily long identifiers. The linker may also limit the maximum symbol length, but C++ symbols containing over 4000 characters have apparently been seen in real programs, so presumably linkers today can handle quite long symbol names. The extra malloc/free of course has a cost, but OTOH in some cases the patch changes strcpy to mere pointer assignments. But to reiterate, this matter only for those symbols which have a binding label. The patch also changes the module format slightly, in that for symbols without a binding label, an empty string is written instead of repeating the name. AFAICS with the patch the compiler can still read pre-patch .mod files, so I didn't bump the module version number. Regtested on x86_64-unknown-linux-gnu, Ok for trunk/4.8? While the patch is long, it's quite mechanical, but OTOH the issue it fixes isn't particularly serious so I think waiting until 4.8 would be fine as well. But I'll leave the decision to the reviewer(s) . 2012-01-13 Janne Blomqvist PR fortran/51808 * decl.c (set_binding_label): Move prototype from match.h to here. (curr_binding_label): Make a pointer rather than static array. (build_sym): Check sym->binding_label pointer rather than array, update set_binding_label call, handle curr_binding_label changes. (set_binding_label): Handle new curr_binding_label, dest_label double ptr, and sym->binding_label. (set_verify_bind_c_sym): Check sym->binding_label pointer rather than array, update set_binding_label call. (gfc_match_bind_c_stmt): Handle curr_binding_label change. (match_procedure_decl): Update set_binding_label call. (gfc_match_bind_c): Change binding_label to pointer, update gfc_match_name_C call. * gfortran.h (GFC_MAX_BINDING_LABEL_LEN): Remove macro. (gfc_symbol): Make binding_label a pointer. (gfc_common_head): Likewise. * match.c (gfc_match_name_C): Heap allocate bind(C) name. * match.h (gfc_match_name_C): Change prototype argument. (set_binding_label): Move prototype to decl.c. * module.c (struct pointer_info): Make binding_label a pointer. (free_pi_tree): Free unused binding_label. (mio_read_string): New function. (mio_write_string): New function. (load_commons): Redo reading of binding_label. (read_module): Likewise. (write_common_0): Change to write empty string instead of name if no binding_label. (write_blank_common): Write empty string for binding label. (write_symbol): Change to write empty string instead of name if no binding_label. * resolve.c (gfc_iso_c_func_interface): Make binding_label a pointer. (set_name_and_label): Make binding_label double pointer, use asprintf. (gfc_iso_c_sub_interface): Make binding_label a pointer. (resolve_bind_c_comms): Handle cases if gfc_common_head->binding_label is NULL. (gfc_verify_binding_labels): sym->binding_label is a pointer. * symbol.c (gfc_free_symbol): Free binding_label. (gfc_new_symbol): Rely on XCNEW zero init for binding_label. (gen_special_c_interop_ptr): Use asprintf. (generate_isocbinding_symbol): Allocate space for binding_label. (get_iso_c_sym): Use pointer assignment instead of strcpy. * trans-common.c (gfc_sym_mangled_common_id): Handle com->binding_label being a pointer. * trans-decl.c (gfc_sym_mangled_identifier): Handle sym->binding_label being a pointer. (gfc_sym_mangled_function_id): Likewise. testsuite ChangeLog 2012-01-13 Janne Blomqvist PR fortran/51808 * gfortran.dg/module_md5_1.f90: Update MD5 sum. -- Janne Blomqvist diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3e553a3..724c8ad 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -34,6 +34,9 @@ along with GCC; see the file COPYING3. If not see #define gfc_get_data() XCNEW (gfc_data) +static gfc_try set_binding_label (char **, const char *, int); + + /* This flag is set if an old-st
Re: [C++ Patch] PR 51225
Hi, On 01/13/2012 01:16 PM, Paolo Carlini wrote: in C++11 mode after erroring out for an undeclared name we can easily end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which has error_mark_node as argument. We should never pass uninstantiated trees to cxx_eval_constant_expression; they need to go through tsubst first. Actually, I'm pretty sure you explained that already in the past, and I have more generally a deja-vu... Anyway, the reason we are not tsubst-ing such trees - eg, a CAST_EXPR on a single element TREE_LIST as argument, with error_mark_node as value - is that potential_constant_expression is false in fold_non_dependent_expr_sfinae, thus tsubst_copy_and_build is not called at all. The reason why potential_constant_expression is false is that recursion leads to the argument as a TREE_LIST and then the next call to the error_mark_node itself, which eventually leads to false. Back to my deja-vu feeling, I'm pretty sure that a few weeks ago I experimented with changing potential_constant_expression to actually return *true* for error_mark_node, and that worked for a similar problem. But maybe my few lines of analysis already inspire you something? Thanks, Paolo.
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Jan 13, 2012, at 11:25 AM, Georg-Johann Lay wrote: > So it's fine to dump any code to the test suite no matter on what platform it > might break or work? No. It isn't fine, but it does happen. Some people spend a lot of time, trying to get the testcases minimal, portable and correct. Other people, can't even be bothered to test the testcase to ensure to actually even tested the failure. :-( The best way forward IMHO, is to not just fix it, but to provide feedback to those that author such testcases, to see if you can sensitize people to some of the issues. Some issues, like, ints are 16 bits, you're going to loose some or most people on most of the time. Other issues, should be easier. Timely feedback I think is the key though, best would be automated testing that can provide feedback within the hour, failing that, nightly.
Re: [Patch, fortran] PR48351 - [OOP] Realloc on assignment fails if parent component is CLASS
Committed as revision 183162. Thanks Tobias - I'll look at yours first thing tomorrow. Paul On Fri, Jan 13, 2012 at 4:50 PM, Tobias Burnus wrote: > On 01/13/2012 04:29 PM, Paul Richard Thomas wrote: >> >> Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk? > > > OK. Thanks for the patch! > > Good that we have __builtin_free counting test cases, which helps to detect > such issues. > > Tobias > > >> 2012-01-12 Paul Thomas >> >> PR fortran/48351 >> * trans-array.c (structure_alloc_comps): Suppress interative >> call to self, when current component is deallocated using >> gfc_trans_dealloc_allocated. >> * class.c (gfc_build_class_symbol): Copy the 'alloc_comp' >> attribute from the declared type to the class structure. >> >> 2012-01-12 Paul Thomas >> >> PR fortran/48351 >> * gfortran.dg/alloc_comp_assign.f03: New. >> * gfortran.dg/allocatable_scalar_9.f90: Reduce count of >> __BUILTIN_FREE from 38 to 32. > > -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
looking for LTR or Marriage
Good day, my friend! Love means to commit oneself without guarantee, to give oneself completely in the hope that our love will produce love in the loved person. Love is an act of faith, and whoever is of little faith is also of little love. I don?t doubt even for a single second that I will be alright, I will find my love one day and we will become the happiest couple in the world. But time passes by and I am still here www.pls-findme.in/ waiting for you and afraid to lose my hope one day. Save me, my love or otherwise I won?t have any reason to enjoy this life. Waiting for your letter gladys
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Jakub Jelinek wrote: > On Fri, Jan 13, 2012 at 08:25:39PM +0100, Georg-Johann Lay wrote: >> So it's fine to dump any code to the test suite no matter on what platform it >> might break or work? > > It is wrong to knowingly commit testcases that break on such platforms, > but you really shouldn't expect every committer to test all testsuite > additions on all targets. > > Jakub I really don't expect anyone to run test suites on any platform or target supported by GCC. Such an approach is completely useless because of the amount of time and system resources and I never proposed that. But it appears that many of the test that are exposed to all targets are just dropped at the testsuite without even looking at them with respect to platform requirements. The most prominent of these requirements is sizeof(int) >= 4 because the most PRs are reported for such platforms. Still I think that patches that are applied to test suite should experience some review. Anything else will just increase annoyance and frustration of developers that work for platforms that are not in the center of bolide hardware. For many test cases it's already sufficient to cut down constants so that they fit into 16 bits, and if actually 32-bit variable is needed GCC provides magic like __INT32_TYPE__. Johann
C++ PATCH for c++/20681 (bogus -Wreturn-type warning)
Here the issue is that in some cases the compiler warns about control
reaching the end of the function when a return is followed by a break.
In the audit trail people noted that the C front end worked around this
issue with
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01452.html
and I've just adopted the same approach.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 00eeabd8273ce6dca5d2ccba45b302119cd798e6
Author: Jason Merrill
Date: Fri Jan 13 14:27:04 2012 -0500
PR c++/20681
* semantics.c (finish_break_stmt): Avoid adding an unreachable
BREAK_STMT.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 6f6f0ac..8c976eb 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -995,6 +995,15 @@ finish_range_for_decl (tree range_for_stmt, tree decl, tree expr)
tree
finish_break_stmt (void)
{
+ /* In switch statements break is sometimes stylistically used after
+ a return statement. This can lead to spurious warnings about
+ control reaching the end of a non-void function when it is
+ inlined. Note that we are calling block_may_fallthru with
+ language specific tree nodes; this works because
+ block_may_fallthru returns true when given something it does not
+ understand. */
+ if (!block_may_fallthru (cur_stmt_list))
+return void_zero_node;
return add_stmt (build_stmt (input_location, BREAK_STMT));
}
diff --git a/gcc/testsuite/g++.dg/warn/Wreturn-type-7.C b/gcc/testsuite/g++.dg/warn/Wreturn-type-7.C
new file mode 100644
index 000..62e34a5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wreturn-type-7.C
@@ -0,0 +1,16 @@
+// PR c++/20681
+// { dg-options -Wreturn-type }
+
+struct a{~a();a();};
+int GetMetaCombination (int a2)
+{
+ a bi;
+ switch (a2)
+ {
+case 1:
+ return 18;
+ break;//removing this works around the warning
+default:
+ return 0;
+ }
+}
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Fri, Jan 13, 2012 at 08:25:39PM +0100, Georg-Johann Lay wrote: > So it's fine to dump any code to the test suite no matter on what platform it > might break or work? It is wrong to knowingly commit testcases that break on such platforms, but you really shouldn't expect every committer to test all testsuite additions on all targets. Jakub
Re: [C++ Patch] PR 51225
On 01/13/2012 01:16 PM, Paolo Carlini wrote: in C++11 mode after erroring out for an undeclared name we can easily end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which has error_mark_node as argument. We should never pass uninstantiated trees to cxx_eval_constant_expression; they need to go through tsubst first. Jason
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Jakub Jelinek wrote: > On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote: >> The ilp32 is the closes match: >> >> The source casts pointer to int, int to pointer, long to int, uses 32-bit >> initializers for int, assumes size_t is unsigned long any maybe others. > > No. The source is just fine for any target where sizeof (long) == sizeof > (void *). > So both ilp32 and lp64. > >> I wonder why such test cases go into the test suite in the first place if the >> come with such bunch of implications. > > Because they test actual problems that were reported and usually fixed with > the same commit, to avoid regressing in the future? > > Jakub So it's fine to dump any code to the test suite no matter on what platform it might break or work? I.e. it is sufficient that it runs on at least one platform that complies to the C standard (for C test case)? Are there really no policies for test case that they behave reasonably? If, for example, there were hundreds of testcases in the test suites that break if sizeof(void) != 2 adding to the fun working with your platform: What would you think? Johann
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote: > The ilp32 is the closes match: > > The source casts pointer to int, int to pointer, long to int, uses 32-bit > initializers for int, assumes size_t is unsigned long any maybe others. No. The source is just fine for any target where sizeof (long) == sizeof (void *). So both ilp32 and lp64. > I wonder why such test cases go into the test suite in the first place if the > come with such bunch of implications. Because they test actual problems that were reported and usually fixed with the same commit, to avoid regressing in the future? Jakub
Re: [Patch,testsuite]: Fix wrong prototype of malloc/memcpy
Mike Stump wrote: > On Jan 13, 2012, at 4:20 AM, Georg-Johann Lay wrote: >> Following test case has wrong prototypes of malloc/memset and this is the >> fix. >> >> * gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy. > > [ be sure to add Ok? to patches you didn't check in, it is easy for me to > think you applied them as obvious if you don't ] The subject line would then look like [Patch,testsuite,committed]: Text and together with a link to the actual commit(s) like here http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00667.html or here http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00626.html Anyways, thanks for your patience with that flood of patches... Johann
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Mike Stump wrote: > On Jan 13, 2012, at 9:23 AM, Rainer Orth wrote: >> Mike Stump writes: >> >>> On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote: This test case is obviously written for 32-bit platforms, thus added "dg-require-effective-target ilp32" to ensure that the pointer mess won't lead to FAILs because of warning: cast to pointer from integer of different size and warning: cast from pointer to integer of different size Ok to apply? >>> Ok. >>> * gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32. >> I wonder if the fix is right, though: the testcase currenly passes for >> 64-bit multilibs, but won't run there any longer if the patch is >> applied. > > I rely upon words like obviously written for 32-bit platforms a little too > much apparently, sorry. I agree, let's find some other solution. I've > starred at the code, and is was not clear to me why you thought it was > obviously for 32-bit platforms. > > So, I'd propose the -Wno- option silence the warning... Seem reasonable to > people, if so, Ok. The ilp32 is the closes match: The source casts pointer to int, int to pointer, long to int, uses 32-bit initializers for int, assumes size_t is unsigned long any maybe others. Test cases like these are a permanent annoyance. There are hundreds of test cases that are not properly written or reviewed or gated by dg-require-foo. I wonder why such test cases go into the test suite in the first place if the come with such bunch of implications. Most of the test cases run on *all* targets that GCC claims to support. Johann
Re: libgo patch committed: Update to weekly.2011-12-22
On Fri, Jan 13, 2012 at 7:00 PM, Ian Lance Taylor wrote: > Uros Bizjak writes: > >>> I have committed a patch to libgo to update it to the weekly.2011-12-22 >>> release. As usual I am not including all the changes here, only the >>> ones to files which are specific to gccgo. Bootstrapped and ran Go >>> testsuite on x86_64-unknown-linux-gnu. Committed to mainline. >> >> After this commit, compile on alphaev68-linux-gnu dies with: >> >> libtool: compile: /space/uros/gcc-build-go/./gcc/gccgo >> -B/space/uros/gcc-build-go/./gcc/ >> -B/usr/local/alphaev68-unknown-linux-gnu/bin/ >> -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem >> /usr/local/alphaev68-unknown-linux-gnu/include -isystem >> /usr/local/alphaev68-unknown-linux-gnu/sys-include -O2 -g -mieee -I . >> -c -fgo-prefix=libgo_exp >> ../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go >> ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go -fPIC -o >> exp/.libs/terminal.o >> ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go:69:23: error: >> reference to undefined identifier ‘syscall.TIOCGWINSZ’ >> make[4]: *** [exp/terminal.lo] Error 1 >> make[4]: *** Waiting for unfinished jobs > > Thanks for the report, but this is surprising. Doesn't Alpha GNU/Linux > define TIOCGWINSZ in /usr/include/asm-generic/ioctls.h? And isn't that > file #include'd, indirectly, by ? > > If not, does Alpha GNU/Linux define TIOCGWINSZ at all, and how does it > define it? I thought TIOCGWINSZ was common, and I'm particularly > surprised to not find it on a GNU/Linux system. This is the same problem with -fdump-go-spec we discussed a couple of months ago [1]. In short, alpha linux doesn't just include with hardcoded numbers in asm/ioctls.h, but builds ioctl arguments as shown in [1]. Probably, this is the right way ... [1] http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00117.html Uros.
Re: libgo patch committed: Update to weekly.2011-12-22
Ian Lance Taylor writes: > I have committed a patch to libgo to update it to the weekly.2011-12-22 > release. As usual I am not including all the changes here, only the > ones to files which are specific to gccgo. Bootstrapped and ran Go > testsuite on x86_64-unknown-linux-gnu. Committed to mainline. This also broke bootstrap on x86_64-unknown-linux-gnu (CentOS 5.5): /vol/gcc/src/hg/trunk/local/libgo/go/net/fd_linux.go:40:46: error: reference to undefined identifier 'syscall.EPOLL_CLOEXEC' Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[C++ Patch] PR 51225
Hi,
in C++11 mode after erroring out for an undeclared name we can easily
end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which
has error_mark_node as argument.
The latter trees are currently completely unhandled by
cxx_eval_constant_expression, thus in order to avoid such ICEs on
invalid it seems safe setting *non_constant_p = true and returning back
t, as we do when t itself is error_mark_node, and asserting errorcount.
The resulting diagnostics is pretty terse.
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-01-13 Paolo Carlini
PR c++/51225
* semantics.c (cxx_eval_constant_expression): Handle CAST_EXPR,
CONST_CAST_EXPR, STATIC_CAST_EXPR, REINTERPRET_CAST_EXPR,
IMPLICIT_CONV_EXPR.
/testsuite
2012-01-13 Paolo Carlini
PR c++/51225
* g++.dg/cpp0x/pr51225.C: New.
Index: testsuite/g++.dg/cpp0x/pr51225.C
===
--- testsuite/g++.dg/cpp0x/pr51225.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51225.C(revision 0)
@@ -0,0 +1,14 @@
+// PR c++/51225
+// { dg-options "-std=c++0x" }
+
+template struct A {};
+
+template void foo()
+{
+ A a; // { dg-error "not declared|invalid type" }
+}
+
+template struct bar
+{
+ static constexpr A<1> a = A<1>(x); // { dg-error "not declared" }
+};
Index: cp/semantics.c
===
--- cp/semantics.c (revision 183153)
+++ cp/semantics.c (working copy)
@@ -7769,6 +7769,15 @@ cxx_eval_constant_expression (const constexpr_call
used, and they can't do anything with it, so just return it. */
return t;
+case CAST_EXPR:
+case CONST_CAST_EXPR:
+case STATIC_CAST_EXPR:
+case REINTERPRET_CAST_EXPR:
+case IMPLICIT_CONV_EXPR:
+ gcc_assert (errorcount);
+ *non_constant_p = true;
+ return t;
+
case LAMBDA_EXPR:
case PREINCREMENT_EXPR:
case POSTINCREMENT_EXPR:
Re: libgo patch committed: Update to weekly.2011-12-22
Uros Bizjak writes: >> I have committed a patch to libgo to update it to the weekly.2011-12-22 >> release. As usual I am not including all the changes here, only the >> ones to files which are specific to gccgo. Bootstrapped and ran Go >> testsuite on x86_64-unknown-linux-gnu. Committed to mainline. > > After this commit, compile on alphaev68-linux-gnu dies with: > > libtool: compile: /space/uros/gcc-build-go/./gcc/gccgo > -B/space/uros/gcc-build-go/./gcc/ > -B/usr/local/alphaev68-unknown-linux-gnu/bin/ > -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem > /usr/local/alphaev68-unknown-linux-gnu/include -isystem > /usr/local/alphaev68-unknown-linux-gnu/sys-include -O2 -g -mieee -I . > -c -fgo-prefix=libgo_exp > ../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go > ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go -fPIC -o > exp/.libs/terminal.o > ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go:69:23: error: > reference to undefined identifier ‘syscall.TIOCGWINSZ’ > make[4]: *** [exp/terminal.lo] Error 1 > make[4]: *** Waiting for unfinished jobs Thanks for the report, but this is surprising. Doesn't Alpha GNU/Linux define TIOCGWINSZ in /usr/include/asm-generic/ioctls.h? And isn't that file #include'd, indirectly, by ? If not, does Alpha GNU/Linux define TIOCGWINSZ at all, and how does it define it? I thought TIOCGWINSZ was common, and I'm particularly surprised to not find it on a GNU/Linux system. Ian
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Jan 13, 2012, at 9:23 AM, Rainer Orth wrote: > Mike Stump writes: > >> On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote: >>> This test case is obviously written for 32-bit platforms, thus added >>> "dg-require-effective-target ilp32" to ensure that the pointer mess won't >>> lead >>> to FAILs because of >>> >>> warning: cast to pointer from integer of different size >>> >>> and >>> >>> warning: cast from pointer to integer of different size >>> >>> Ok to apply? >> >> Ok. >> >>> * gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32. > > I wonder if the fix is right, though: the testcase currenly passes for > 64-bit multilibs, but won't run there any longer if the patch is > applied. I rely upon words like obviously written for 32-bit platforms a little too much apparently, sorry. I agree, let's find some other solution. I've starred at the code, and is was not clear to me why you thought it was obviously for 32-bit platforms. So, I'd propose the -Wno- option silence the warning... Seem reasonable to people, if so, Ok.
C++ PATCH for c++/51813 (visibility of template instantiation)
For PR 35688 I fixed the compiler to reduce the visibility of a template
instantiation based on the visibility of its template arguments. As a
result of this, we seem to have started marking some external symbols as
.hidden because:
1) One of the template arguments is hidden, so the instantiation is as well.
2) The template has DECL_VISIBILITY_SPECIFIED because it is inside a
namespace with a visibility attribute.
3) default_binds_local_p_1 decides that a decl with explicit non-default
visibility binds locally, so it gets a .hidden directive.
The issue here is that there is no explicit non-default visibility, so
we should clear DECL_VISIBILITY_SPECIFIED when reducing the visibility
of a declaration.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5b39abcbdeb088fe7c19c7ff1a280ca4f7876366
Author: Jason Merrill
Date: Fri Jan 13 12:39:40 2012 -0500
PR c++/51813
* decl2.c (constrain_visibility): Clear DECL_VISIBILITY_SPECIFIED
when reducing the visibility.
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 05f4b42..0cde6c6 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1984,6 +1984,8 @@ constrain_visibility (tree decl, int visibility, bool tmpl)
&& (tmpl || !DECL_VISIBILITY_SPECIFIED (decl)))
{
DECL_VISIBILITY (decl) = (enum symbol_visibility) visibility;
+ /* This visibility was not specified. */
+ DECL_VISIBILITY_SPECIFIED (decl) = false;
}
}
diff --git a/gcc/testsuite/g++.dg/ext/visibility/template9.C b/gcc/testsuite/g++.dg/ext/visibility/template9.C
new file mode 100644
index 000..d160846
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/visibility/template9.C
@@ -0,0 +1,14 @@
+// PR c++/51813
+// { dg-options -fvisibility=hidden }
+// { dg-final { scan-assembler-not "hidden\\s+_ZN1N1fI1AEEvT" } }
+
+struct A { };
+namespace N __attribute((visibility("default"))) {
+ template void f(T) { }
+ extern template void f(A);
+}
+
+int main()
+{
+ N::f(A());
+}
Re: Merged r183086 and r183143 from branches/google/gcc-4_6. (issue 5541046)
LGTM
On Thu, Jan 12, 2012 at 3:16 PM, wrote:
>
> Reviewers: xur, shenhan, jingyu,
>
> Message:
> This merges in the fix for ICE when using PGO when building Chrome.
>
>
>
> Please review this at http://codereview.appspot.com/5541046/
>
> Affected files:
> M .
> M gcc/ChangeLog.google-4_6
> M gcc/profile.c
>
>
> Index: .
> ===
> --- . (revision 183143)
> +++ . (working copy)
>
> Property changes on: .
> ___
> Modified: svn:mergeinfo
> Merged /branches/google/gcc-4_6:r183086,183143
> Index: gcc/ChangeLog.google-4_6
> ===
> --- gcc/ChangeLog.google-4_6 (revision 183143)
> +++ gcc/ChangeLog.google-4_6 (working copy)
> @@ -1,3 +1,16 @@
> +2012-01-12 Rong Xu
> + Backport r183142 from google/main
> +
> + * gcc/profile.c (compute_value_histograms): ignore the
> + histrogram when the counters not found in gcda file.
> +
> +2012-01-10 Rong Xu
> +
> + Backport r183081 from google/main
> +
> + * gcc/profile.c (compute_value_histograms): handle the
> + case when INDIR_CALL counters not available in gcda files.
> +
> 2011-12-19 Han Shen
> Add a new option "-fstack-protector-strong".
> * cfgexpand.c (expand_used_vars): Add logic handling
> Index: gcc/profile.c
> ===
> --- gcc/profile.c (revision 183143)
> +++ gcc/profile.c (working copy)
> @@ -790,9 +790,14 @@
> gcov_type *histogram_counts[GCOV_N_VALUE_COUNTERS];
> gcov_type *act_count[GCOV_N_VALUE_COUNTERS];
> gcov_type *aact_count;
> + bool warned[GCOV_N_VALUE_COUNTERS];
> + static const char *const ctr_names[] = GCOV_COUNTER_NAMES;
>
> for (t = 0; t < GCOV_N_VALUE_COUNTERS; t++)
> - n_histogram_counters[t] = 0;
> + {
> + n_histogram_counters[t] = 0;
> + warned[t] = 0;
> + }
>
> for (i = 0; i < VEC_length (histogram_value, values); i++)
> {
> @@ -828,6 +833,19 @@
> t = (int) hist->type;
>
> aact_count = act_count[t];
> + /* If cannot find the counters in gcda file, skip and give
> + a warning. */
> + if (aact_count == 0)
> + {
> + if (!warned[t] && flag_opt_info >= OPT_INFO_MIN)
> + warning (0, "cannot find %s counters in function %s.",
> + ctr_names[COUNTER_FOR_HIST_TYPE(t)],
> + IDENTIFIER_POINTER (
> + DECL_ASSEMBLER_NAME (current_function_decl)));
> + hist->n_counters = 0;
> + warned[t] = true;
> + continue;
> + }
> act_count[t] += hist->n_counters;
>
> gimple_add_histogram_value (cfun, stmt, hist);
>
>
Re: [Patch,testsuite]: Again: Fix wrong assumption on sizeof (int)
On Jan 13, 2012, at 1:42 AM, Georg-Johann Lay wrote: > This is again a test case that assumes sizeof (int) > 2 which is not true in > general. > > * g++.dg/ipa/pr51759.C: Fix assumption sizeof(int) > 2. > > Ok for trunk. Ok.
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Mike Stump writes: > On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote: >> This test case is obviously written for 32-bit platforms, thus added >> "dg-require-effective-target ilp32" to ensure that the pointer mess won't >> lead >> to FAILs because of >> >> warning: cast to pointer from integer of different size >> >> and >> >> warning: cast from pointer to integer of different size >> >> Ok to apply? > > Ok. > >> * gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32. I wonder if the fix is right, though: the testcase currenly passes for 64-bit multilibs, but won't run there any longer if the patch is applied. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch,testsuite]: Fix yet another test case that breaks because it assumes sizeof(int) > 2
On Fri, Jan 13, 2012 at 09:12:25AM -0800, Mike Stump wrote: > On Jan 13, 2012, at 2:16 AM, Georg-Johann Lay wrote: > > Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does > > not. > > Fixed as obvious is usually the term we use when work is checked in. > > > Ok for trunk? > > Ok for trunk is the term we use for work that hasn't been checked in. So, > I'm left wondering if the work is in or not. > > Anyway, after reviewing the PR, it seems like they need a large enough > offset to require 4 bytes of displacement size, and 1<<15 I suspect isn't > actually large enough. I think the proposed change removes a valuable > test, so I don't think it is ok. Yeah, this change is definitely wrong. Georg-Johann, please, any time you propose similar changes always try to reproduce the bug that was actually being fixed by the PR in the question, with some older and newer compiler, and see if your changes don't make the testcase useless as in this case. Obviously changes to require int32plus or similar don't need such investigation. Jakub
Fix regression on PR46590 (slow compile with -O0)
Hi,
the stack-var conflict generation code needs 13 (out of 34) seconds, with
-O0 on the second testcase of PR46590. Most of the time is spent in
generating the same conflicts again and again at each basic block (the
time right now is O(nr-of-bbs * N^2) where the number of conflicts is
O(N^2)).
If we simply remember for which partitions we already generated the lower
triangular conflict matrix we don't have to do that again, lowering the
overall time to O(N^2).
This patch does that. Time for variable expansion now is 0.4 seconds (of
overall 22).
Regstrapping in progress on x86_64-linux, okay for trunk?
Ciao,
Michael.
* cfgexpand.c (add_scope_conflicts_1): New old_conflicts argument,
use it in remembering which conflicts we already created.
(add_scope_conflicts): Adjust call to above, (de)allocate helper
bitmap.
Index: cfgexpand.c
===
*** cfgexpand.c (revision 183155)
--- cfgexpand.c (working copy)
*** visit_conflict (gimple stmt ATTRIBUTE_UN
*** 441,451
/* Helper routine for add_scope_conflicts, calculating the active partitions
at the end of BB, leaving the result in WORK. We're called to generate
!conflicts when FOR_CONFLICT is true, otherwise we're just tracking
!liveness. */
static void
! add_scope_conflicts_1 (basic_block bb, bitmap work, bool for_conflict)
{
edge e;
edge_iterator ei;
--- 441,452
/* Helper routine for add_scope_conflicts, calculating the active partitions
at the end of BB, leaving the result in WORK. We're called to generate
!conflicts when OLD_CONFLICTS is non-null, otherwise we're just tracking
!liveness. If we generate conflicts then OLD_CONFLICTS stores the bits
!for which we generated conflicts already. */
static void
! add_scope_conflicts_1 (basic_block bb, bitmap work, bitmap old_conflicts)
{
edge e;
edge_iterator ei;
*** add_scope_conflicts_1 (basic_block bb, b
*** 482,488
}
else if (!is_gimple_debug (stmt))
{
! if (for_conflict
&& visit == visit_op)
{
/* If this is the first real instruction in this BB we need
--- 483,489
}
else if (!is_gimple_debug (stmt))
{
! if (old_conflicts
&& visit == visit_op)
{
/* If this is the first real instruction in this BB we need
*** add_scope_conflicts_1 (basic_block bb, b
*** 490,505
Unlike classical liveness for named objects we can't
rely on seeing a def/use of the names we're interested in.
There might merely be indirect loads/stores. We'd not add any
!conflicts for such partitions. */
bitmap_iterator bi;
unsigned i;
! EXECUTE_IF_SET_IN_BITMAP (work, 0, i, bi)
{
unsigned j;
bitmap_iterator bj;
! EXECUTE_IF_SET_IN_BITMAP (work, i + 1, j, bj)
add_stack_var_conflict (i, j);
}
visit = visit_conflict;
}
walk_stmt_load_store_addr_ops (stmt, work, visit, visit, visit);
--- 491,521
Unlike classical liveness for named objects we can't
rely on seeing a def/use of the names we're interested in.
There might merely be indirect loads/stores. We'd not add any
!conflicts for such partitions. We know that we generated
!conflicts between all partitions in old_conflicts already,
!so we need to generate only the new ones, avoiding to
!repeatedly pay the O(N^2) cost for each basic block. */
bitmap_iterator bi;
unsigned i;
!
! /* First the conflicts between new and old_conflicts members. */
! EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i, bi)
{
unsigned j;
bitmap_iterator bj;
! EXECUTE_IF_SET_IN_BITMAP (old_conflicts, 0, j, bj)
add_stack_var_conflict (i, j);
}
+ /* Then the conflicts between only the new members. */
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i, bi)
+ {
+ unsigned j;
+ bitmap_iterator bj;
+ EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, j, bj)
+ add_stack_var_conflict (i, j);
+ }
+ /* And remember for the next basic block. */
+ bitmap_ior_into (old_conflicts, work);
visit = visit_conflict;
}
walk_stmt_load_store_addr_ops (stmt, work, visit, visit, visit);
*** add_scope_conflicts (void)
*** 516,521
--- 532,538 --
Re: [v3] Link libstdc++ with -lpthread on IRIX 6 (PR target/47852)
> 2011-02-25 Rainer Orth > > PR target/47852 > * configure.host (irix6.5*): Add -lpthread to OPT_LDFLAGS. > OK -benjamin
Re: [PATCH][C] Fix PR37985
On Fri, 13 Jan 2012, Richard Guenther wrote: > This fixes PR37985 where since > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we > mark conversions produced by convert_to_integer with TREE_NO_WARNING. > This may shadow "real" stmts with no effects, thus we should > simply strip them again before checking for TREE_SIDE_EFFECTS. > > Bootstrap & regtest pending on x86_64-unknown-linux-gnu. > > Ok if that passes? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote: > This test case is obviously written for 32-bit platforms, thus added > "dg-require-effective-target ilp32" to ensure that the pointer mess won't lead > to FAILs because of > > warning: cast to pointer from integer of different size > > and > > warning: cast from pointer to integer of different size > > Ok to apply? Ok. > * gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32.
Re: [Patch,testsuite]: Fix wrong prototype of malloc/memcpy
On Jan 13, 2012, at 4:20 AM, Georg-Johann Lay wrote: > Following test case has wrong prototypes of malloc/memset and this is the fix. > > * gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy. [ be sure to add Ok? to patches you didn't check in, it is easy for me to think you applied them as obvious if you don't ] Ok.
Re: [Patch,testsuite]: Fix testcase with sizeof(void*) < 4
On Jan 13, 2012, at 4:01 AM, Georg-Johann Lay wrote: > This patch adds -Wno-pointer-to-int-cast to the options in order to avoid FAIL > because of "warning: cast from pointer to integer of different size" when > sizeof(void*) = 2. Ok. > * gcc.dg/pr50527.c: Don't FAIL if sizeof(void*) = 2
Re: [Patch,testsuite]: Fix yet another test case that breaks because it assumes sizeof(int) > 2
On Jan 13, 2012, at 2:16 AM, Georg-Johann Lay wrote:
> Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does not.
Fixed as obvious is usually the term we use when work is checked in.
> Ok for trunk?
Ok for trunk is the term we use for work that hasn't been checked in. So, I'm
left wondering if the work is in or not.
Anyway, after reviewing the PR, it seems like they need a large enough offset
to require 4 bytes of displacement size, and 1<<15 I suspect isn't actually
large enough. I think the proposed change removes a valuable test, so I don't
think it is ok.
Instead, skip the testcase on int16 systems, or require int32 and larger
systems... Ok with that change.
> * gcc.dg/debug/dwarf2/pr49871.c: Fix to work on int16 platforms.
>
>
> Index: gcc.dg/debug/dwarf2/pr49871.c
> ===
> --- gcc.dg/debug/dwarf2/pr49871.c (revision 183150)
> +++ gcc.dg/debug/dwarf2/pr49871.c (working copy)
> @@ -4,7 +4,7 @@
>
> struct S
> {
> - char a[1 << 16];
> + char a[1 << 15];
> int b;
> } s;
Re: [PATCH] Fix PR33763
On Fri, Jan 13, 2012 at 11:05:36AM +0100, Richard Guenther wrote:
> This fixes the ICEs that occur with redeclared extern inline functions
> in some circumstances. It avoids the cgraph confusion by _not_ merging
> the two decls in this case but simply drops the old (extern inline)
> one on the floor. This causes the cgraph to be properly presented
> with two different decls and thus two different cgraph nodes will
> be created. I didn't try to change name-lookup to always find
> the extern inline copy to preserve the ever existing recursive
> case
>
> extern __inline __attribute__ ((__always_inline__))
> void open ()
> {
> }
> void open ()
> {
> open ();
> }
>
> which even in 3.2 where the ICEs appearantly did not exist compiled
> to a self-recursive open () (trivially explained by how 3.2 worked,
> function-at-a-time).
That won't e.g. copy over any attributes from the extern inline to
the out of line, or asm redirection, or type merging, etc.
If you want to keep olddecl as is, then IMHO we should add a new bool
argument to merge_decls and if the flag is set, make sure we only ever
modify newdecl and not olddecl.
Jakub
[Patch] gcc-4.7/changes.html - tone down -fcoarray=lib announcement
Dear all, seemingly may (potential) users still do not realize that gfortran's multi-image coarray support is not yet usable as only the basic libcaf infrastructure (registering, deregistering, argument passing, syncing, start up/close down, error stop - and all the coindex handling routines) is implemented. The actual communication (pull/push coarray data, locking) does not yet work. Hence, although a lot of progress has been made in term of infrastructure, multi-images are still not usable - not even for hello world programs. (Unless you count "print *, this_image(),' of ', num_images; end" as a such.) I would be happy if someone could check the patch below but also the following pages whether it is clear that they should not yet use -fcoarray=lib with more than one image. a) Release notes (cf. patch below): http://gcc.gnu.org/gcc-4.7/changes.html#fortran b) Wiki release notes: http://gcc.gnu.org/wiki/GFortran#GCC4.7 c) Coarrays in general: http://gcc.gnu.org/wiki/Coarray d) The most important page - as is describes how to compile the library version: http://gcc.gnu.org/wiki/CoarrayLib Tobias Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.73 diff -u -p -r1.73 changes.html --- changes.html12 Jan 2012 19:35:29 - 1.73 +++ changes.html13 Jan 2012 16:39:40 - @@ -504,7 +504,8 @@ well. Additionally, preliminary support for multiple images via an MPI-based http://gcc.gnu.org/wiki/CoarrayLib";> coarray communication library has been added. Note: - Remote coarray access is not yet possible. + The library version is not yet usable as remote coarray + access is not yet possible. http://gcc.gnu.org/wiki/TS29113Status";>TS 29113:
Re: [patch,testsuite]: Fix yet another test case that breaks on int16 platforms
On Jan 13, 2012, at 2:10 AM, Georg-Johann Lay wrote: > Similar to fix for gcc.dg/cpp/warn-multichar-2.c: It's sifficient to have a > 2-letter constant. > > Ok to apply? Ok.
Re: [Patch,testsuite]: Fix test case for int=16 platforms
On Jan 13, 2012, at 2:07 AM, Georg-Johann Lay wrote: > This fixed multi-char testcase that would otherwise lead to "constant exceeds > its type" message and thus FAIL. > > Use 2-letter constant is sufficient and don't break on int=16 platforms. > > Ok to apply? Ok.
Re: [Patch, fortran] PR48351 - [OOP] Realloc on assignment fails if parent component is CLASS
On 01/13/2012 04:29 PM, Paul Richard Thomas wrote: Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk? OK. Thanks for the patch! Good that we have __builtin_free counting test cases, which helps to detect such issues. Tobias 2012-01-12 Paul Thomas PR fortran/48351 * trans-array.c (structure_alloc_comps): Suppress interative call to self, when current component is deallocated using gfc_trans_dealloc_allocated. * class.c (gfc_build_class_symbol): Copy the 'alloc_comp' attribute from the declared type to the class structure. 2012-01-12 Paul Thomas PR fortran/48351 * gfortran.dg/alloc_comp_assign.f03: New. * gfortran.dg/allocatable_scalar_9.f90: Reduce count of __BUILTIN_FREE from 38 to 32.
C++ PATCH for c++/51620 (C++11 ICE with private dtor)
Making a thunk to a deleted virtual function was making G++ very
confused. Fixed by using __cxa_deleted_virtual for deleted virtual
functions, as specified by the ABI.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 2bf4059b4ebc1c1966b7b4ba94f520f7c0022ca0
Author: Jason Merrill
Date: Fri Jan 13 00:59:56 2012 -0500
PR c++/51620
* class.c (build_vtbl_initializer): Use __cxa_deleted_virtual.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 58c89d3..9b957fe 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -8352,6 +8352,18 @@ build_vtbl_initializer (tree binfo,
init = abort_fndecl_addr;
}
}
+ /* Likewise for deleted virtuals. */
+ else if (DECL_DELETED_FN (fn_original))
+ {
+ fn = get_identifier ("__cxa_deleted_virtual");
+ if (!get_global_value_if_present (fn, &fn))
+ fn = push_library_fn (fn, (build_function_type_list
+ (void_type_node, NULL_TREE)),
+ NULL_TREE);
+ if (!TARGET_VTABLE_USES_DESCRIPTORS)
+ init = fold_convert (vfunc_ptr_type_node,
+ build_fold_addr_expr (fn));
+ }
else
{
if (!integer_zerop (delta) || vcall_index)
diff --git a/gcc/testsuite/g++.dg/cpp0x/defaulted34.C b/gcc/testsuite/g++.dg/cpp0x/defaulted34.C
new file mode 100644
index 000..0821992
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/defaulted34.C
@@ -0,0 +1,10 @@
+// { dg-options -std=c++0x }
+// { dg-final { scan-assembler "__cxa_deleted_virtual" } }
+
+struct A
+{
+ virtual void f();
+ virtual ~A() = delete;
+};
+
+void A::f() {}
diff --git a/gcc/testsuite/g++.dg/template/virtual3.C b/gcc/testsuite/g++.dg/template/virtual3.C
new file mode 100644
index 000..9fcfc45
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/virtual3.C
@@ -0,0 +1,11 @@
+// PR c++/51620
+
+template class A
+{
+ virtual ~A(); // { dg-error "non-deleted|private" }
+};
+
+struct B : A<0>, A<1> // { dg-error "deleted|context" }
+{
+ B() {} // { dg-error "context" }
+};
Re: [Patch, Fortran] PR 51842 use ptrdiff_t for array indices
On Fri, Jan 13, 2012 at 16:07, Tobias Burnus wrote: > Dear all, > > the front end uses for array indices (gfc_index_integer_kind / > gfc_array_index_type) which is a signed integer of size POINTER_SIZE. > > The libgfortran library used to use > typedef ssize_t index_type; > which fails if sizeof(void*) is not sizeof(ssize_t); the latter is the case > on LP64 systems (see PR). As a minor nitpick, not necessarily: E.g. x86_64-linux-gnu and most 64-bit Unix targets are also LP64 (as in, long and pointer are 64 bits), but older releases work there as ssize_t is also 64 bits. The target in the PR is (was?) thus a bit "special", in that while it's LP64, ssize_t is smaller than 64 bits. > For 4.7 this was changed (in April 2011) to: > typedef ptrdiff_t index_type; > which makes more sense - and should be sufficient for LP64 systems. > > However, mixing an POINTER_SIZE type with ptrdiff_t only works if > sizeof(ptrdiff_t) == POINTER_SIZE; in principle, the maximally allowed size > of a variable can be smaller (e.g. page size) than the maximally allowed > pointer size. (sizeof() returns a result of type size_t). I do not know > whether such systems exist in practice and whether such a system is > supported by GCC. > > The attached patch makes let's the FE emit code of the same data type as > used in libgfortran - ptrdiff_t for the array indices. > > Build and regtested on x86-64-linux. > OK for the trunk? Ok, thanks. -- Janne Blomqvist
[Patch, fortran] PR48351 - [OOP] Realloc on assignment fails if parent component is CLASS
Dear All,
When the only modification was to set the attribute alloc_comp for
class containers, I was going to commit this patch as obvious.
However, it caused a regression in class-19.f03 by increasing the
count of BUILTIN_FREE from 11 to 23! Whilst the extra calls did no
harm, this offended my sensibilities excessively :-) The fix to
trans-array.c (structure_alloc_comps) is a bit more invasive, so I
thought that I had better come to the list for approval. Note that
this 'bug' applied to other cases and was the cause of the
proliferation of free's in allocatable_scalar_9.f90. I have checked
the code for this case and everything that should be freed is
freed just once .
Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk?
Paul
2012-01-12 Paul Thomas
PR fortran/48351
* trans-array.c (structure_alloc_comps): Suppress interative
call to self, when current component is deallocated using
gfc_trans_dealloc_allocated.
* class.c (gfc_build_class_symbol): Copy the 'alloc_comp'
attribute from the declared type to the class structure.
2012-01-12 Paul Thomas
PR fortran/48351
* gfortran.dg/alloc_comp_assign.f03: New.
* gfortran.dg/allocatable_scalar_9.f90: Reduce count of
__BUILTIN_FREE from 38 to 32.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 183125)
--- gcc/fortran/trans-array.c (working copy)
*** structure_alloc_comps (gfc_symbol * der_
*** 7238,7243
--- 7238,7244
gfc_loopinfo loop;
stmtblock_t fnblock;
stmtblock_t loopbody;
+ stmtblock_t tmpblock;
tree decl_type;
tree tmp;
tree comp;
*** structure_alloc_comps (gfc_symbol * der_
*** 7249,7254
--- 7250,7256
tree ctype;
tree vref, dref;
tree null_cond = NULL_TREE;
+ bool called_dealloc_with_status;
gfc_init_block (&fnblock);
*** structure_alloc_comps (gfc_symbol * der_
*** 7359,7375
switch (purpose)
{
case DEALLOCATE_ALLOC_COMP:
! if (cmp_has_alloc_comps && !c->attr.pointer)
! {
! /* Do not deallocate the components of ultimate pointer
! components. */
! comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
! decl, cdecl, NULL_TREE);
! rank = c->as ? c->as->rank : 0;
! tmp = structure_alloc_comps (c->ts.u.derived, comp, NULL_TREE,
! rank, purpose);
! gfc_add_expr_to_block (&fnblock, tmp);
! }
if (c->attr.allocatable
&& (c->attr.dimension || c->attr.codimension))
--- 7361,7372
switch (purpose)
{
case DEALLOCATE_ALLOC_COMP:
!
! /* gfc_deallocate_scalar_with_status calls gfc_deallocate_alloc_comp
! (ie. this function) so generate all the calls and suppress the
! recursion from here, if necessary. */
! called_dealloc_with_status = false;
! gfc_init_block (&tmpblock);
if (c->attr.allocatable
&& (c->attr.dimension || c->attr.codimension))
*** structure_alloc_comps (gfc_symbol * der_
*** 7377,7383
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
tmp = gfc_trans_dealloc_allocated (comp, c->attr.codimension);
! gfc_add_expr_to_block (&fnblock, tmp);
}
else if (c->attr.allocatable)
{
--- 7374,7380
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
tmp = gfc_trans_dealloc_allocated (comp, c->attr.codimension);
! gfc_add_expr_to_block (&tmpblock, tmp);
}
else if (c->attr.allocatable)
{
*** structure_alloc_comps (gfc_symbol * der_
*** 7387,7398
tmp = gfc_deallocate_scalar_with_status (comp, NULL, true, NULL,
c->ts);
! gfc_add_expr_to_block (&fnblock, tmp);
tmp = fold_build2_loc (input_location, MODIFY_EXPR,
void_type_node, comp,
build_int_cst (TREE_TYPE (comp), 0));
! gfc_add_expr_to_block (&fnblock, tmp);
}
else if (c->ts.type == BT_CLASS && CLASS_DATA (c)->attr.allocatable)
{
--- 7384,7396
tmp = gfc_deallocate_scalar_with_status (comp, NULL, true, NULL,
c->ts);
! gfc_add_expr_to_block (&tmpblock, tmp);
! called_dealloc_with_status = true;
tmp = fold_build2_loc (input_location, MODIFY_EXPR,
void_type_node, comp,
build_int_cst (TREE_TYPE (comp), 0));
! gfc_add_expr_to_block (&tmpblock, tmp);
}
else if (c->ts.type == BT_CLASS && CLASS_DATA (c)->attr.allocatable)
{
*** structure_alloc_comps (gfc_symbol * der_
*** 7412,7425
{
tmp = gfc_deallocate_scalar_with_status (comp, NULL, true, NULL,
CLASS_DATA (c)->ts);
! gfc_add_expr_to_block (&fnblock, t
Re: [wwwdocs] gcc-4.7/porting_to.html
> I went ahead and created a small patch with the changes above which > is the second patch below and committed it. If you'd like to see > some changes, just let me know. Thanks Gerald! This looks good. For the links, I just tried to add them where they'd been added before. Seems reasonable -benjamin
Re: [PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
Denis Chertykov wrote:
> Committed
>
> Denis
Consider code prom PR51374
void __vector_18 (void)
{
extern char slot;
unsigned char status = (*(volatile unsigned char*) 0x2B);
unsigned char data = (*(volatile unsigned char*) 0x2C);
if (status & 0x10)
slot = 0;
}
the code with -Os -S -dp sets up a frame pointer which is not needed and should
not be there:
__vector_18:
push r28 ; 28 pushqi1/1 [length = 1]
push r29 ; 29 pushqi1/1 [length = 1]
in r28,__SP_L__ ; 30 *movhi/8[length = 2]
in r29,__SP_H__
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
in r24,0xc ; 8 movqi_insn/4[length = 1]
sbis 0xb,4 ; 11 *sbix_branch[length = 2]
rjmp .L1
sts slot,__zero_reg__; 13 movqi_insn/3[length = 2]
.L1:
/* epilogue start */
pop r29 ; 33 popqi [length = 1]
pop r28 ; 34 popqi [length = 1]
ret ; 35 return_from_epilogue[length = 1]
This happens even for empty function.
Johann
[Patch, Fortran] PR 51842 use ptrdiff_t for array indices
Dear all, the front end uses for array indices (gfc_index_integer_kind / gfc_array_index_type) which is a signed integer of size POINTER_SIZE. The libgfortran library used to use typedef ssize_t index_type; which fails if sizeof(void*) is not sizeof(ssize_t); the latter is the case on LP64 systems (see PR). For 4.7 this was changed (in April 2011) to: typedef ptrdiff_t index_type; which makes more sense - and should be sufficient for LP64 systems. However, mixing an POINTER_SIZE type with ptrdiff_t only works if sizeof(ptrdiff_t) == POINTER_SIZE; in principle, the maximally allowed size of a variable can be smaller (e.g. page size) than the maximally allowed pointer size. (sizeof() returns a result of type size_t). I do not know whether such systems exist in practice and whether such a system is supported by GCC. The attached patch makes let's the FE emit code of the same data type as used in libgfortran - ptrdiff_t for the array indices. Build and regtested on x86-64-linux. OK for the trunk? Tobias 2012-01-13 Tobias Burnus PR fortran/51842 * fortran/trans-types.c (gfc_init_kinds): Use PTRDIFF_TYPE instead of a signed int of size POINTER_SIZE for gfc_index_integer_kind. diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c index d643c2e..f817a12 100644 --- a/gcc/fortran/trans-types.c +++ b/gcc/fortran/trans-types.c @@ -576,8 +576,8 @@ gfc_init_kinds (void) gfc_default_character_kind = gfc_character_kinds[0].kind; gfc_character_storage_size = gfc_default_character_kind * 8; - /* Choose the integer kind the same size as "void*" for our index kind. */ - gfc_index_integer_kind = POINTER_SIZE / 8; + gfc_index_integer_kind = get_int_kind_from_name (PTRDIFF_TYPE); + /* Pick a kind the same size as the C "int" type. */ gfc_c_int_kind = INT_TYPE_SIZE / 8;
[Patch,testsuite]: Fix testcase that bangs long and int against void*
This test case is obviously written for 32-bit platforms, thus added
"dg-require-effective-target ilp32" to ensure that the pointer mess won't lead
to FAILs because of
warning: cast to pointer from integer of different size
and
warning: cast from pointer to integer of different size
Ok to apply?
* gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32.
Index: gcc.dg/lto/20091013-1_0.c
===
--- gcc.dg/lto/20091013-1_0.c (revision 183150)
+++ gcc.dg/lto/20091013-1_0.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-lto-do link } */
/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target ilp32 } */
/* { dg-lto-options {{-fPIC -r -nostdlib -flto} {-fPIC -r -nostdlib -O2
-flto}} } */
void * HeapAlloc(void*,unsigned int,unsigned long);
[Patch,testsuite]: Fix wrong prototype of malloc/memcpy
Following test case has wrong prototypes of malloc/memset and this is the fix.
* gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy.
Index: gcc.dg/lto/20090218-2_1.c
===
--- gcc.dg/lto/20090218-2_1.c (revision 183150)
+++ gcc.dg/lto/20090218-2_1.c (working copy)
@@ -4,8 +4,8 @@ int main(void)
{
return 0;
}
-void *malloc(unsigned long size);
-void *memcpy(void *dest, const void *src, unsigned long n);
+void *malloc(__SIZE_TYPE__ size);
+void *memcpy(void *dest, const void *src, __SIZE_TYPE__ n);
static mem_attrs * get_mem_attrs () {
void **slot;
*slot = malloc (3);
[Patch,testsuite]: Fix testcase with sizeof(void*) < 4
This patch adds -Wno-pointer-to-int-cast to the options in order to avoid FAIL
because of "warning: cast from pointer to integer of different size" when
sizeof(void*) = 2.
* gcc.dg/pr50527.c: Don't FAIL if sizeof(void*) = 2
Index: gcc.dg/pr50527.c
===
--- gcc.dg/pr50527.c(revision 183150)
+++ gcc.dg/pr50527.c(working copy)
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-Os --param large-stack-frame=30" } */
+/* { dg-options "-Os --param large-stack-frame=30 -Wno-pointer-to-int-cast" }
*/
extern void abort (void);
Re: [PATCH] Fix PR33763
On Fri, 13 Jan 2012, Richard Guenther wrote:
>
> This fixes the ICEs that occur with redeclared extern inline functions
> in some circumstances. It avoids the cgraph confusion by _not_ merging
> the two decls in this case but simply drops the old (extern inline)
> one on the floor. This causes the cgraph to be properly presented
> with two different decls and thus two different cgraph nodes will
> be created. I didn't try to change name-lookup to always find
> the extern inline copy to preserve the ever existing recursive
> case
>
> extern __inline __attribute__ ((__always_inline__))
> void open ()
> {
> }
> void open ()
> {
> open ();
> }
>
> which even in 3.2 where the ICEs appearantly did not exist compiled
> to a self-recursive open () (trivially explained by how 3.2 worked,
> function-at-a-time).
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Ok for trunk?
This FAILs
FAIL: gcc.dg/inline3.c (test for warnings, line 6)
FAIL: gcc.dg/inline3.c (test for errors, line 7)
because we end up calling duplicate_decls with olddecl being
the extern inline copy twice - somehow the bindings are messed
up (read: don't work naturally?).
In particular we put the extern inline fn in both the
external and current scope (and thus the file-scope decl
initially shadows the extern "copy"). We're then doing
/* If this is an external linkage declaration, we should check
for compatibility with the type in the external scope before
setting the type at this scope based on the visible
information only. */
if (TREE_PUBLIC (x) && TREE_PUBLIC (visdecl))
{
while (b_ext && !B_IN_EXTERNAL_SCOPE (b_ext))
b_ext = b_ext->shadowed;
if (b_ext)
{
b_use = b_ext;
if (b_use->u.type)
TREE_TYPE (b_use->decl) = b_use->u.type;
}
}
finding that extern inline 'extern scope' copy and disambiguate
against that.
I suppose extern inline fns should not be put in external_scope?
Thus,
@@ -2776,7 +2794,8 @@ pushdecl (tree x)
nested = true;
x = visdecl;
}
- else
+ else if (!(DECL_DECLARED_INLINE_P (x)
+&& DECL_EXTERNAL (x)))
{
bind (name, x, external_scope, /*invisible=*/true,
/*nested=*/false, locus);
in addition to the patch below?
Thanks,
Richard.
> Thanks,
> Richard.
>
> 2012-01-13 Richard Guenther
>
> PR c/33763
> * c-decl.c (duplicate_decls): Do not merge re-declared extern
> inline function decls with their re-declaration.
>
> * gcc.dg/torture/pr33763-1.c: New testcase.
> * gcc.dg/torture/pr33763-2.c: Likewise.
> * gcc.dg/torture/pr33763-3.c: Likewise.
>
> Index: gcc/c-decl.c
> ===
> *** gcc/c-decl.c (revision 183121)
> --- gcc/c-decl.c (working copy)
> *** duplicate_decls (tree newdecl, tree oldd
> *** 2513,2518
> --- 2513,2536
> return false;
> }
>
> + /* If we have a redeclared extern inline function simply drop olddecl
> + on the floor instead of merging it with newdecl. */
> + if (TREE_CODE (newdecl) == FUNCTION_DECL
> + && DECL_INITIAL (newdecl)
> + && DECL_INITIAL (olddecl)
> + && !(!(DECL_DECLARED_INLINE_P (olddecl)
> + && DECL_EXTERNAL (olddecl))
> +|| (DECL_DECLARED_INLINE_P (newdecl)
> +&& DECL_EXTERNAL (newdecl))
> +|| (!flag_gnu89_inline
> +&& (!DECL_DECLARED_INLINE_P (olddecl)
> +|| !lookup_attribute ("gnu_inline",
> + DECL_ATTRIBUTES (olddecl)))
> +&& (!DECL_DECLARED_INLINE_P (newdecl)
> +|| !lookup_attribute ("gnu_inline",
> + DECL_ATTRIBUTES (newdecl))
> + return false;
> +
> merge_decls (newdecl, olddecl, newtype, oldtype);
> return true;
> }
> Index: gcc/testsuite/gcc.dg/torture/pr33763-1.c
> ===
> *** gcc/testsuite/gcc.dg/torture/pr33763-1.c (revision 0)
> --- gcc/testsuite/gcc.dg/torture/pr33763-1.c (revision 0)
> ***
> *** 0
> --- 1,41
> + /* { dg-do run } */
> +
> + extern __inline __attribute__ ((__always_inline__))
> + int foo ()
> + {
> + return 1;
> + }
> + int test1 ()
> + {
> + /* Name-lookup should find foo that returns 1. */
> + return foo ();
> + }
> + int foo ()
> + {
> + return 0;
> + }
> +
> + extern __inline __attribute__ ((__always_inline__))
> + int bar ()
> + {
> + return 1;
> + }
> + int bar ()
> + {
> + return 0;
> + }
> + int test2 ()
> + {
> + /* Name-lookup should find bar that returns 0. */
> + return bar ();
> + }
> +
> + int
> + main()
> + {
> + if (test1 () != 1)
> + abort ();
> + if (test2 () != 0)
> +
Re: [PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
2012/1/13 Georg-Johann Lay : > Denis Chertykov wrote: >> Georg-Johann Lay: >>> Denis Chertykov schrieb: >>> >>> 2) Can we remove from avr.c:avr_option_override() the following: >>> >>> if (avr_strict_X) >>> flag_caller_saves = 0; >>> >>> that hacked around similar spill fails? >>> >>> 3) As PR50775 is fixed: Would it make sense to turn on >>> -mstrict-X per default now, i.e. no more fake X >>> addressing except requested per -mno-strict-X? >> >> This bug (and it's fix) isn't related to this addressing problems. > > The addressing is/was connected to spill fails: -mstrict-X increased register > pressure so that there were spill fails if -fcaller-saves was turned on, too. > > So the question is: will -mstrict-X work together with -fcaller-saves without > raising spill fails in difficult reload situations? Nothing changed in this area. -mstrict-X will rise spill fails in difficult reload situations. > > If -mstrict-X is "safe" in the way that it does not lead to spill fails > because > reload cannot cope with the few address registers, then we could turn on > -mstrict-X by default and get rid of fake addressing. Nothing changed in this area. The reload is a reload as is. > > The reason why -mstrict-X is not on per default was that the risk of spill > fails was estimated as too high (no problem of mstrict-X but of reload). Yes. I'm agree with you - no problem of mstrict-X but of reload. The fake addressing exists only because of this. Denis.
[PATCH][C] Fix PR37985
This fixes PR37985 where since
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
mark conversions produced by convert_to_integer with TREE_NO_WARNING.
This may shadow "real" stmts with no effects, thus we should
simply strip them again before checking for TREE_SIDE_EFFECTS.
Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
Ok if that passes?
Thanks,
Richard.
2012-01-13 Richard Guenther
PR c/37985
* c-typeck.c (emit_side_effect_warnings): Strip conversions
with TREE_NO_WARNING.
* gcc.dg/Wunused-value-4.c: New testcase.
Index: gcc/c-typeck.c
===
*** gcc/c-typeck.c (revision 183121)
--- gcc/c-typeck.c (working copy)
*** c_finish_bc_stmt (location_t loc, tree *
*** 9163,9168
--- 9163,9172
static void
emit_side_effect_warnings (location_t loc, tree expr)
{
+ /* Strip conversions marked with TREE_NO_WARNING. */
+ while (TREE_NO_WARNING (expr) && CONVERT_EXPR_P (expr))
+ expr = TREE_OPERAND (expr, 0);
+
if (expr == error_mark_node)
;
else if (!TREE_SIDE_EFFECTS (expr))
Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
===
*** gcc/testsuite/gcc.dg/Wunused-value-4.c (revision 0)
--- gcc/testsuite/gcc.dg/Wunused-value-4.c (revision 0)
***
*** 0
--- 1,9
+ /* PR c/37985 */
+ /* { dg-do compile } */
+ /* { dg-options "-Wunused-value" } */
+
+ unsigned char foo(unsigned char a)
+ {
+ a >> 2; /* { dg-warning "statement with no effect" } */
+ return a;
+ }
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
On 01/13/2012 10:58 AM, Richard Sandiford wrote:
> Yes, because new test ALWAYS includes the registers that were wrongly
> marked as dead by previous test due to REG_UNUSED and noclobber
> processing.
Or to put it another way: the insn-to-insn changes in the current liveness
sets are all produced by df_simulate_one_insn_{backwards,forwards}, which
uses the same information. So I don't think there's any reason why we
need to keep the current code as well.
Yes, both explanations are sound. I think the patch is good, too.
Paolo
[Patch,testsuite,AVR,committed]: Set BRANCH_COST > 1 in gcc.dg/pr46309.c
http://gcc.gnu.org/viewcvs?view=revision&revision=183151
As explained in its comment, the test case works only if BRANCH_COST > 1.
This is done by the patch.
* gcc.dg/pr46309.c: Set branch cost to greater 1 for avr.
--- trunk/gcc/testsuite/gcc.dg/pr46309.c2012/01/13 05:11:45 183150
+++ trunk/gcc/testsuite/gcc.dg/pr46309.c2012/01/13 10:32:16 183151
@@ -4,6 +4,7 @@
/* The transformation depends on BRANCH_COST being greater than 1
(see the notes in the PR), so try to force that. */
/* { dg-additional-options "-mtune=octeon2" { target mips*-*-* } } */
+/* { dg-additional-options "-mbranch-cost=2" { target avr*-*-* } } */
int
f1 (int a)
[RFC combine] PR48308 - Fix issue with missing(?) LOG_LINKS
Hi, PR48308 is a case where on the ARM port we incorrectly delete a call to strcmp assuming that this is dead. However the problem starts early enough in combine where when try_combine is given i2 of the form (parallel [(set (reg:CC X) (compare:CC OP (const_int 0))) (set Y OP)]) and i1 is NULL it transforms this to : (set Y OP) and change I2 to be (set (reg:CC X) (compare:CC Y (const_int 0))) but in the snippet of code that changes i1 and i2 we don't seem to update LOG_LINKS . We then go and check if i1_feeds_into_i2 and that check relies on the LOG_LINKS being up-to-date. We find that i2 can be combined with i3 *but* we've then gone and made a transformation that results in Y being used but miss out emitting the set of Y. The attached patch appears to fix the problem for the reduced testcase and reduced^2 testcase attached to PR48308. Unfortunately this doesn't fix the testcase from PR50313 which prima-facie was a dup of this bug which I'm still investigating. This has survived bootstrap on x86_64 and is running tests there ( though based on a quick reading of the x86 backend I couldn't find any parallels of that form) and is still undergoing a full bootstrap run on an ARM board. Thoughts ? cheers Ramana diff --git a/gcc/combine.c b/gcc/combine.c index 4178870..f6b8769 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -2865,6 +2865,8 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx i0, int *new_direct_jump_p, SUBST (PATTERN (i2), XVECEXP (PATTERN (i2), 0, 0)); SUBST (XEXP (SET_SRC (PATTERN (i2)), 0), SET_DEST (PATTERN (i1))); + LOG_LINKS (i2) = alloc_insn_link (i1, LOG_LINKS (i2)); + } } #endif
Re: useless_type_conversion_p vs pointer sizes
On Jan 13, 2012, at 10:30 AM, Richard Guenther wrote:
> On Fri, Jan 13, 2012 at 12:09 AM, DJ Delorie wrote:
>>
>> Another case where one address space may support multiple pointer
>> sizes, so conversions between such must be preserved.
>>
>>* tree-ssa.c (useless_type_conversion_p): Conversions between
>>different-sized pointers aren't useless.
>>
>> Index: tree-ssa.c
>> ===
>> --- tree-ssa.c (revision 183139)
>> +++ tree-ssa.c (working copy)
>> @@ -1192,12 +1192,17 @@ bool
>> useless_type_conversion_p (tree outer_type, tree inner_type)
>> {
>> /* Do the following before stripping toplevel qualifiers. */
>> if (POINTER_TYPE_P (inner_type)
>> && POINTER_TYPE_P (outer_type))
>> {
>> + /* Do not lose casts between pointers of different precision. */
>> + if (TYPE_PRECISION (outer_type)
>> + != TYPE_PRECISION (inner_type))
>> + return false;
>> +
>> /* Do not lose casts between pointers to different address spaces. */
>> if (TYPE_ADDR_SPACE (TREE_TYPE (outer_type))
>> != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
>>return false;
>>
>> /* If the outer type is (void *), the conversion is not necessary. */
>
> That should not be necessary as there is a mode check below. Do you
> hit the issue only when the VOID_TYPE_P check is true? In that case
> simply delete it - it has become obsolete.
We hit the same issue for VMS while compiling libada. I just checked that
removing the check fixes the crash.
Just for the record.
Tristan.
[PATCH] Fix PR8081, VLA returns of nested functions
This fixes the PR by making sure to use RSO for calls to nested
functions that return variable-sized types. This is necessary
because GIMPLE cannot handle calls with an embedded assignment
of variable size (we can't put the WITH_SIZE_EXPR anywhere) and
thus we would ICE later when not using RSO.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-13 Richard Guenther
PR middle-end/8081
* gimplify.c (gimplify_modify_expr_rhs): For calls with a
variable-sized result always use RSO.
* gcc.dg/torture/pr8081.c: New testcase.
Index: gcc/gimplify.c
===
*** gcc/gimplify.c (revision 183121)
--- gcc/gimplify.c (working copy)
*** gimplify_modify_expr_rhs (tree *expr_p,
*** 4417,4422
--- 4417,4427
/* It's OK to use the target directly if it's being
initialized. */
use_target = true;
+ else if (variably_modified_type_p (TREE_TYPE (*to_p), NULL_TREE))
+ /* Always use the target and thus RSO for variable-sized types.
+ GIMPLE cannot deal with a variable-sized assignment
+ embedded in a call statement. */
+ use_target = true;
else if (TREE_CODE (*to_p) != SSA_NAME
&& (!is_gimple_variable (*to_p)
|| needs_to_live_in_memory (*to_p)))
Index: gcc/testsuite/gcc.dg/torture/pr8081.c
===
*** gcc/testsuite/gcc.dg/torture/pr8081.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr8081.c (revision 0)
***
*** 0
--- 1,26
+ /* { dg-do run } */
+
+ extern void abort (void);
+ int
+ main (int argc, char **argv)
+ {
+ int size = 10;
+ typedef struct
+ {
+ char val[size];
+ }
+ block;
+ block a, b;
+ block __attribute__((noinline))
+ retframe_block ()
+ {
+ return *(block *) &b;
+ }
+ b.val[0] = -1;
+ b.val[9] = -2;
+ a=retframe_block ();
+ if (a.val[0] != -1
+ || a.val[9] != -2)
+ abort ();
+ return 0;
+ }
Re: libgo patch committed: Update to weekly.2011-12-22
Hello! > I have committed a patch to libgo to update it to the weekly.2011-12-22 > release. As usual I am not including all the changes here, only the > ones to files which are specific to gccgo. Bootstrapped and ran Go > testsuite on x86_64-unknown-linux-gnu. Committed to mainline. After this commit, compile on alphaev68-linux-gnu dies with: libtool: compile: /space/uros/gcc-build-go/./gcc/gccgo -B/space/uros/gcc-build-go/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys-include -O2 -g -mieee -I . -c -fgo-prefix=libgo_exp ../../../gcc-svn/trunk/libgo/go/exp/terminal/terminal.go ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go -fPIC -o exp/.libs/terminal.o ../../../gcc-svn/trunk/libgo/go/exp/terminal/util.go:69:23: error: reference to undefined identifier ‘syscall.TIOCGWINSZ’ make[4]: *** [exp/terminal.lo] Error 1 make[4]: *** Waiting for unfinished jobs Uros.
[Patch,testsuite]: Fix yet another test case that breaks because it assumes sizeof(int) > 2
Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does not.
Ok for trunk?
Johann
* gcc.dg/debug/dwarf2/pr49871.c: Fix to work on int16 platforms.
Index: gcc.dg/debug/dwarf2/pr49871.c
===
--- gcc.dg/debug/dwarf2/pr49871.c (revision 183150)
+++ gcc.dg/debug/dwarf2/pr49871.c (working copy)
@@ -4,7 +4,7 @@
struct S
{
- char a[1 << 16];
+ char a[1 << 15];
int b;
} s;
Re: [C++ Patch] deprecation of access declarations
Hi, 2012/1/7 Gerald Pfeifer : > On Thu, 29 Dec 2011, Fabien Chêne wrote: >> As previously announced, here is a patch that deprecate access >> declarations . I did a little tour in the GCC museum old-deja --and in >> g++.dg as well -- to disinter and adjust those dusty tests. To avoid >> false positive on invalid code, I have decided to only emit the >> warning if the access declaration is actually valid. > > Mind suggesting a snippt for our release notes at > http://gcc.gnu.org/gcc-4.7/changes.html ? Yes, sure, thanks for suggestion. Unfortunately, my machine is currently down, I'll get back to you when it is repaired. -- Fabien
[patch,testsuite]: Fix yet another test case that breaks on int16 platforms
Similar to fix for gcc.dg/cpp/warn-multichar-2.c: It's sifficient to have a
2-letter constant.
Ok to apply?
Johann
* gcc.dg/cpp/warn-multichar.c: Fix to work on int=16 platforms.
Index: gcc.dg/cpp/warn-multichar.c
===
--- gcc.dg/cpp/warn-multichar.c (revision 183150)
+++ gcc.dg/cpp/warn-multichar.c (working copy)
@@ -1,5 +1,5 @@
// { dg-do preprocess }
// { dg-options "-std=gnu99 -fdiagnostics-show-option -Wmultichar" }
-#if 'abc' // { dg-warning "multi-character character constant .-Wmultichar." }
+#if 'ab' // { dg-warning "multi-character character constant .-Wmultichar." }
#endif
[Patch,testsuite]: Fix test case for int=16 platforms
This fixed multi-char testcase that would otherwise lead to "constant exceeds
its type" message and thus FAIL.
Use 2-letter constant is sufficient and don't break on int=16 platforms.
Ok to apply?
Johann
* gcc.dg/cpp/warn-multichar-2.c: Fix to work on int=16 platforms.
Index: gcc.dg/cpp/warn-multichar-2.c
===
--- gcc.dg/cpp/warn-multichar-2.c (revision 183150)
+++ gcc.dg/cpp/warn-multichar-2.c (working copy)
@@ -1,5 +1,5 @@
// { dg-do preprocess }
// { dg-options "-std=gnu99 -fdiagnostics-show-option -Werror=multichar" }
/* { dg-message "some warnings being treated as errors" "" {target "*-*-*"} 0
} */
-#if 'abc' // { dg-error "multi-character character constant
.-Werror=multichar." }
+#if 'ab' // { dg-error "multi-character character constant
.-Werror=multichar." }
#endif
[PATCH] Fix PR33763
This fixes the ICEs that occur with redeclared extern inline functions
in some circumstances. It avoids the cgraph confusion by _not_ merging
the two decls in this case but simply drops the old (extern inline)
one on the floor. This causes the cgraph to be properly presented
with two different decls and thus two different cgraph nodes will
be created. I didn't try to change name-lookup to always find
the extern inline copy to preserve the ever existing recursive
case
extern __inline __attribute__ ((__always_inline__))
void open ()
{
}
void open ()
{
open ();
}
which even in 3.2 where the ICEs appearantly did not exist compiled
to a self-recursive open () (trivially explained by how 3.2 worked,
function-at-a-time).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Ok for trunk?
Thanks,
Richard.
2012-01-13 Richard Guenther
PR c/33763
* c-decl.c (duplicate_decls): Do not merge re-declared extern
inline function decls with their re-declaration.
* gcc.dg/torture/pr33763-1.c: New testcase.
* gcc.dg/torture/pr33763-2.c: Likewise.
* gcc.dg/torture/pr33763-3.c: Likewise.
Index: gcc/c-decl.c
===
*** gcc/c-decl.c(revision 183121)
--- gcc/c-decl.c(working copy)
*** duplicate_decls (tree newdecl, tree oldd
*** 2513,2518
--- 2513,2536
return false;
}
+ /* If we have a redeclared extern inline function simply drop olddecl
+ on the floor instead of merging it with newdecl. */
+ if (TREE_CODE (newdecl) == FUNCTION_DECL
+ && DECL_INITIAL (newdecl)
+ && DECL_INITIAL (olddecl)
+ && !(!(DECL_DECLARED_INLINE_P (olddecl)
+&& DECL_EXTERNAL (olddecl))
+ || (DECL_DECLARED_INLINE_P (newdecl)
+ && DECL_EXTERNAL (newdecl))
+ || (!flag_gnu89_inline
+ && (!DECL_DECLARED_INLINE_P (olddecl)
+ || !lookup_attribute ("gnu_inline",
+DECL_ATTRIBUTES (olddecl)))
+ && (!DECL_DECLARED_INLINE_P (newdecl)
+ || !lookup_attribute ("gnu_inline",
+DECL_ATTRIBUTES (newdecl))
+ return false;
+
merge_decls (newdecl, olddecl, newtype, oldtype);
return true;
}
Index: gcc/testsuite/gcc.dg/torture/pr33763-1.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
***
*** 0
--- 1,41
+ /* { dg-do run } */
+
+ extern __inline __attribute__ ((__always_inline__))
+ int foo ()
+ {
+ return 1;
+ }
+ int test1 ()
+ {
+ /* Name-lookup should find foo that returns 1. */
+ return foo ();
+ }
+ int foo ()
+ {
+ return 0;
+ }
+
+ extern __inline __attribute__ ((__always_inline__))
+ int bar ()
+ {
+ return 1;
+ }
+ int bar ()
+ {
+ return 0;
+ }
+ int test2 ()
+ {
+ /* Name-lookup should find bar that returns 0. */
+ return bar ();
+ }
+
+ int
+ main()
+ {
+ if (test1 () != 1)
+ abort ();
+ if (test2 () != 0)
+ abort ();
+ return 0;
+ }
Index: gcc/testsuite/gcc.dg/torture/pr33763-2.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
***
*** 0
--- 1,30
+ /* { dg-do compile } */
+
+ extern int foo (const char *, int);
+ extern int baz (const char *, int);
+
+ extern inline __attribute__ ((always_inline, gnu_inline)) int
+ baz (const char *x, int y)
+ {
+ return 2;
+ }
+
+ int
+ baz (const char *x, int y)
+ {
+ return 1;
+ }
+
+ int xa, xb;
+
+ static int
+ inl (const char *x, int y)
+ {
+ return baz (x, y);
+ }
+
+ int
+ foo (const char *x, int y)
+ {
+ return inl (x, y);
+ }
Index: gcc/testsuite/gcc.dg/torture/pr33763-3.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-3.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-3.c(revision 0)
***
*** 0
--- 1,58
+ /* { dg-do compile } */
+
+ typedef struct
+ {
+ void *a;
+ void *b;
+ } T;
+ extern void *foo (const char *, const char *);
+ extern void *bar (void *, const char *, T);
+ extern int baz (const char *, int);
+
+ extern inline __attribute__ ((always_inline, gnu_inline)) int
+ baz (const char *x, int y)
+ {
+ return 2;
+ }
+
+ int
+ baz (const char *x, int y)
+ {
+ return 1;
+ }
+
+ int xa, xb;
+
+ static void *
+ inl (const char *x, const char *y)
+ {
+ T t = { &xa, &xb };
+ int *f = (int *) __builtin_malloc (sizeof (int));
+ const char *z;
+ int o = 0;
+ void *r = 0;
+
+ for (z = y; *z; z++)
+ {
+ if (*z == 'r')
+ o |= 1;
+ if (*z == 'w')
+ o |= 2;
+ }
+ if (o == 1)
+ *f = baz (x, 0
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
Uros Bizjak writes:
> On Fri, Jan 13, 2012 at 10:00 AM, Eric Botcazou wrote:
>>> The problem my patch solves is the answer to the question "Is the
>>> choosen non-live temporary register untouched over the insn
>>> sequence?". The answer: "Yes, if it was not set or clobbered by any
>>> insn in the sequence".
>>
>> Are you sure that you don't need to do this in addition to the existing test,
>> instead of in lieu of the existing test?
>
> Yes, because new test ALWAYS includes the registers that were wrongly
> marked as dead by previous test due to REG_UNUSED and noclobber
> processing.
Yeah, the patch looks like the right fix to me FWIW. Being able to use
DF_INSN_DEFS in this way is part of the point of having df: when going
from one insn to the next within the same bb, there are no "hidden"
influences that would cause a register to become live outside of
DF_INSN_DEFS. The only requirement is that we call df_insn_rescan
on new instructions, and we do (in peep2_update_life, where we need
it for df_simulate_one_insn_backwards).
Or to put it another way: the insn-to-insn changes in the current liveness
sets are all produced by df_simulate_one_insn_{backwards,forwards}, which
uses the same information. So I don't think there's any reason why we
need to keep the current code as well.
Richard
Re: [wwwdocs] Link from gcc-4.{6,7}/changes.html to porting_to.html
Hi Gerald, On 01/13/2012 09:28 AM, Gerald Pfeifer wrote: On Thu, 12 Jan 2012, Tobias Burnus wrote: I intent to commit the attached patch to link I believe Benjamin committed this yesterday, right? Thanks for raising the issue, these links are good to have. Yes - albeit as last item of Caveats which I think makes it harder to find. But at least there is now a link. Thanks, Benjamin, for the committal and for writing porting_to.html! Tobias
[Patch,testsuite]: Again: Fix wrong assumption on sizeof (int)
This is again a test case that assumes sizeof (int) > 2 which is not true in
general.
* g++.dg/ipa/pr51759.C: Fix assumption sizeof(int) > 2.
Ok for trunk.
Index: testsuite/g++.dg/ipa/pr51759.C
===
--- testsuite/g++.dg/ipa/pr51759.C (revision 183150)
+++ testsuite/g++.dg/ipa/pr51759.C (working copy)
@@ -1,6 +1,10 @@
/* { dg-do run } */
/* { dg-options "-O2" } */
+#if __SIZEOF_INT__ == 2 && __SIZEOF_LONG__ == 4
+#define unsigned unsigned long
+#endif
+
extern "C" void abort (void);
struct S
{
Re: useless_type_conversion_p vs pointer sizes
On Fri, Jan 13, 2012 at 12:09 AM, DJ Delorie wrote:
>
> Another case where one address space may support multiple pointer
> sizes, so conversions between such must be preserved.
>
> * tree-ssa.c (useless_type_conversion_p): Conversions between
> different-sized pointers aren't useless.
>
> Index: tree-ssa.c
> ===
> --- tree-ssa.c (revision 183139)
> +++ tree-ssa.c (working copy)
> @@ -1192,12 +1192,17 @@ bool
> useless_type_conversion_p (tree outer_type, tree inner_type)
> {
> /* Do the following before stripping toplevel qualifiers. */
> if (POINTER_TYPE_P (inner_type)
> && POINTER_TYPE_P (outer_type))
> {
> + /* Do not lose casts between pointers of different precision. */
> + if (TYPE_PRECISION (outer_type)
> + != TYPE_PRECISION (inner_type))
> + return false;
> +
> /* Do not lose casts between pointers to different address spaces. */
> if (TYPE_ADDR_SPACE (TREE_TYPE (outer_type))
> != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
> return false;
>
> /* If the outer type is (void *), the conversion is not necessary. */
That should not be necessary as there is a mode check below. Do you
hit the issue only when the VOID_TYPE_P check is true? In that case
simply delete it - it has become obsolete.
Richard.
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
On Fri, Jan 13, 2012 at 10:00 AM, Eric Botcazou wrote: >> Yes, it is a complete solution. Tracking register liveness is >> different issue, and a register is indeed dead after instruction, if >> it has been clobbered by insn, or when marked unused. > > My concern was liveness within the new sequence of instructions: suppose you > have > > (set (reg:M x) (...)) REG_UNUSED (reg:M x) > > and we "peephole" the instruction. Is the live range of (reg:M x) properly > extended within the new sequence of instructions? The patch doesn't change this functionality, but: (match_scratch:M 1 "r") (set (reg:M x) (...)) REG_UNUSED (reg:M x) (match_dup 1) Previously, register x would be allocated as a scracth register, but now it isn't. Regarding the liveness analysis of a new sequence - this functionality is not changed at all. As said, the new code only prevents x to be allocated as a scratch that must live up to the (match_dup 1). >> The problem my patch solves is the answer to the question "Is the >> choosen non-live temporary register untouched over the insn >> sequence?". The answer: "Yes, if it was not set or clobbered by any >> insn in the sequence". > > Are you sure that you don't need to do this in addition to the existing test, > instead of in lieu of the existing test? Yes, because new test ALWAYS includes the registers that were wrongly marked as dead by previous test due to REG_UNUSED and noclobber processing. Uros.
Re: [PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
Denis Chertykov wrote: > Georg-Johann Lay: >> Denis Chertykov schrieb: >> >> 2) Can we remove from avr.c:avr_option_override() the following: >> >> if (avr_strict_X) >> flag_caller_saves = 0; >> >> that hacked around similar spill fails? >> >> 3) As PR50775 is fixed: Would it make sense to turn on >> -mstrict-X per default now, i.e. no more fake X >> addressing except requested per -mno-strict-X? > > This bug (and it's fix) isn't related to this addressing problems. The addressing is/was connected to spill fails: -mstrict-X increased register pressure so that there were spill fails if -fcaller-saves was turned on, too. So the question is: will -mstrict-X work together with -fcaller-saves without raising spill fails in difficult reload situations? If -mstrict-X is "safe" in the way that it does not lead to spill fails because reload cannot cope with the few address registers, then we could turn on -mstrict-X by default and get rid of fake addressing. The reason why -mstrict-X is not on per default was that the risk of spill fails was estimated as too high (no problem of mstrict-X but of reload). Johann
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
> Yes, it is a complete solution. Tracking register liveness is > different issue, and a register is indeed dead after instruction, if > it has been clobbered by insn, or when marked unused. My concern was liveness within the new sequence of instructions: suppose you have (set (reg:M x) (...)) REG_UNUSED (reg:M x) and we "peephole" the instruction. Is the live range of (reg:M x) properly extended within the new sequence of instructions? > The problem my patch solves is the answer to the question "Is the > choosen non-live temporary register untouched over the insn > sequence?". The answer: "Yes, if it was not set or clobbered by any > insn in the sequence". Are you sure that you don't need to do this in addition to the existing test, instead of in lieu of the existing test? -- Eric Botcazou
Re: [wwwdocs] Link from gcc-4.{6,7}/changes.html to porting_to.html
Hi Tobias, On Thu, 12 Jan 2012, Tobias Burnus wrote: I intent to commit the attached patch to link I believe Benjamin committed this yesterday, right? Thanks for raising the issue, these links are good to have. Gerald
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
On Fri, Jan 13, 2012 at 12:01 AM, Eric Botcazou wrote:
>> The solution is to fix the scanning loop to look into the insn pattern
>> itself for all set and clobbered hard registers. This way, all
>> registers, clobbered by the pattern, will be correctly marked in the
>> "live" bitmap, including FLAGS register that is ignored by current
>> approach.
>>
>> 2012-01-12 Uros Bizjak
>>
>> * recog.c (peep2_find_free_register): Determine clobbered registers
>> from insn pattern.
>
> Is that a complete solution though? Don't we need to do more, for example
> because of peep2_reg_dead_p and peep2_update_life? These are not rhetorical
> questions, but genuine ones; it's a little disturbing to discover such a flaw
> in this kind of code after all these years (I can reproduce the problem with
> all the compilers of the 4.x series, so this didn't work with flow.c either).
Yes, it is a complete solution. Tracking register liveness is
different issue, and a register is indeed dead after instruction, if
it has been clobbered by insn, or when marked unused. This works OK,
and there are many examples of peep2_{reg|regno}_dead_p usag in
i386.md.
The problem my patch solves is the answer to the question "Is the
choosen non-live temporary register untouched over the insn
sequence?". The answer: "Yes, if it was not set or clobbered by any
insn in the sequence".
Uros.
