[PATCH] Fix a typo in sparseset_pop
Hi The following patch fixes an obvious wrong index used to access the dense array. The patch has passed the bootstrap and regression tests on x86-64. OK for trunk? thanks Carrot 2014-02-23 Guozhi Wei * sparseset.h (sparseset_pop): Fix the wrong index. Index: sparseset.h === --- sparseset.h (revision 208039) +++ sparseset.h (working copy) @@ -177,7 +177,7 @@ gcc_checking_assert (mem != 0); s->members = mem - 1; - return s->dense[mem]; + return s->dense[s->members]; } static inline void
[PATCH] Fix PR c++/25940
Hi,
The following patch fixes two issues: the first is PR c++/25940 and the second
is related to PR c++/13699.
The first issue is that the C++ frontend fails to reject duplicate definitions
of functions with C language linkage. This results in the compiler emitting
ASM that defines the same symbol more than once.
The second issue is that upon encountering a redeclaration of an extern "C"
function with a different exception specification, the C++ frontend fails to
add the new declaration to the list of things declared in the current
namespace. This makes the new declaration appear to be not in scope.
I bootstrapped and regtested this patch on x86_64-unknown-linux-gnu. I had a
few guality and cilk FAILs but I don't think they are related to this patch.
PR c++/25940
* name-lookup.c (pushdecl_maybe_friend_1): Bail when a function
with C language linkage is redefined. Don't return
error_mark_node after a function with C language linkage is
redeclared with a different exception specification.
(lookup_extern_c_fun_in_all_ns): Prefer returning an existing
function definition instead of a declaration.
PR c++/25940
* g++.dg/lookup/extern-c-redecl6.C: New test.
* g++.dg/lookup/extern-c-redecl7.C: New test.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index ea16061..0ee4f4c 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -861,6 +861,15 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
tree x_exception_spec = NULL_TREE;
tree previous_exception_spec = NULL_TREE;
+ if (DECL_INITIAL (x) && DECL_INITIAL (previous))
+ {
+ error_at (input_location,
+ "redefinition of %q+#D with C language linkage",
+ x);
+ inform (input_location,
+ "%q+#D previously defined here", previous);
+ return error_mark_node;
+ }
x_exception_spec =
TYPE_RAISES_EXCEPTIONS (TREE_TYPE (x));
previous_exception_spec =
@@ -877,7 +886,6 @@ pushdecl_maybe_friend_1 (tree x, bool is_friend)
previous);
pedwarn (input_location, 0,
"due to different exception specifications");
- return error_mark_node;
}
if (DECL_ASSEMBLER_NAME_SET_P (previous))
SET_DECL_ASSEMBLER_NAME (x,
@@ -2142,8 +2150,10 @@ binding_for_name (cp_binding_level *scope, tree name)
}
/* Walk through the bindings associated to the name of FUNCTION,
- and return the first declaration of a function with a
- "C" linkage specification, a.k.a 'extern "C"'.
+ and return the first definition of a function with a
+ "C" linkage specification, a.k.a 'extern "C"'. If no previous
+ definition exists, return the first declaration of the function.
+
This function looks for the binding, regardless of which scope it
has been defined in. It basically looks in all the known scopes.
Note that this function does not lookup for bindings of builtin functions
@@ -2152,6 +2162,7 @@ static tree
lookup_extern_c_fun_in_all_ns (tree function)
{
tree name;
+ tree ret = NULL_TREE;
cxx_binding *iter;
gcc_assert (function && TREE_CODE (function) == FUNCTION_DECL);
@@ -2172,11 +2183,14 @@ lookup_extern_c_fun_in_all_ns (tree function)
&& DECL_EXTERN_C_P (decl)
&& !DECL_ARTIFICIAL (decl))
{
- return decl;
+ if (DECL_INITIAL (decl))
+ return decl;
+ if (!ret)
+ ret = decl;
}
}
}
- return NULL;
+ return ret;
}
/* Returns a list of C-linkage decls with the name NAME. */
diff --git a/gcc/testsuite/g++.dg/lookup/extern-c-redecl6.C
b/gcc/testsuite/g++.dg/lookup/extern-c-redecl6.C
new file mode 100644
index 000..37424d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/extern-c-redecl6.C
@@ -0,0 +1,29 @@
+// PR c++/25940
+
+namespace X {
+ extern "C" void foo () throw ();
+}
+
+namespace A {
+ extern "C" void foo () // { dg-message "previously defined" }
+ {
+ }
+}
+
+namespace Y {
+ extern "C" void foo ();
+}
+
+namespace B {
+ extern "C" void foo () // { dg-error "redefinition" }
+ {
+ }
+}
+
+namespace Z {
+ extern "C" void foo ();
+}
+
+extern "C" void foo () // { dg-error "redefinition" }
+{
+}
diff --git a/gcc/testsuite/g++.dg/lookup/extern-c-redecl7.C
b/gcc/testsuite/g++.dg/lookup/extern-c-redecl7.C
new file mode 100644
index 000..2210417
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/extern-c-redecl7.C
@@ -0,0 +1,12 @@
+namespace A {
+ extern "C" void foo () throw (); // { dg-error "previous declaration" }
+}
+
+namespace B {
+ extern "C" void foo (); // { dg
Re: [PATCH v2] PR middle-end/60281
Hi everyone,
no comments for my patch?
于 2014年02月21日 10:43, lin zuojian 写道:
> Hi,
> I have misunderstood the meaning of STRICT_ALIGNMENT.Sorry for that Jakub.
> I think patch v2 have modified as Jakub suggested.
>
>
> ---
> Without aligning the asan stack base,this base will only 64-bit aligned
> in ARM machines.
> But asan require 256-bit aligned base because of this:
> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
> 2.store multiple/load multiple instructions require the other 2 bits are
> zeros
>
> that add up lowest 5 bits should be zeros.That means 32 bytes or 256
> bits aligned.
>
> * asan.c (asan_emit_stack_protection): Forcing the base to align to 256
> bits if STRICT_ALIGNMENT.
> And set shadow_mem align to 256 bits if STRICT_ALIGNMENT
> * cfgexpand.c (expand_stack_vars): set base_align appropriately when
> asan is on
> (expand_used_vars): Leaving a space in the stack frame for alignment if
> STRICT_ALIGNMENT
> ---
> gcc/asan.c | 10 ++
> gcc/cfgexpand.c | 13 -
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/asan.c b/gcc/asan.c
> index 53992a8..8d8ad50 100644
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -1017,8 +1017,16 @@ asan_emit_stack_protection (rtx base, rtx pbase,
> unsigned int alignb,
> base_align_bias = ((asan_frame_size + alignb - 1)
> & ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size;
> }
> + /* Align base if target is STRICT_ALIGNMENT. */
> + if (STRICT_ALIGNMENT)
> + base = expand_binop (Pmode, and_optab, base,
> + gen_int_mode (-((GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) /
> BITS_PER_UNIT), Pmode),
> + NULL_RTX, 1, OPTAB_DIRECT);
> +
> if (use_after_return_class == -1 && pbase)
> emit_move_insn (pbase, base);
> +
> +
> base = expand_binop (Pmode, add_optab, base,
> gen_int_mode (base_offset - base_align_bias, Pmode),
> NULL_RTX, 1, OPTAB_DIRECT);
> @@ -1097,6 +1105,8 @@ asan_emit_stack_protection (rtx base, rtx pbase,
> unsigned int alignb,
> && (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
> shadow_mem = gen_rtx_MEM (SImode, shadow_base);
> set_mem_alias_set (shadow_mem, asan_shadow_set);
> + if (STRICT_ALIGNMENT)
> + set_mem_align(shadow_mem, (GET_MODE_ALIGNMENT (SImode) <<
> ASAN_SHADOW_SHIFT));
> prev_offset = base_offset;
> for (l = length; l; l -= 2)
> {
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index 06d494c..63d8020 100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -1013,10 +1013,18 @@ expand_stack_vars (bool (*pred) (size_t), struct
> stack_vars_data *data)
> if (data->asan_base == NULL)
> data->asan_base = gen_reg_rtx (Pmode);
> base = data->asan_base;
> +
> + if (!STRICT_ALIGNMENT)
> + base_align = crtl->max_used_stack_slot_alignment;
> + else
> + base_align = MAX(crtl->max_used_stack_slot_alignment,
> + (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT));
> }
> else
> + {
> offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
> - base_align = crtl->max_used_stack_slot_alignment;
> + base_align = crtl->max_used_stack_slot_alignment;
> + }
> }
> else
> {
> @@ -1843,6 +1851,9 @@ expand_used_vars (void)
> = alloc_stack_frame_space (redzonesz, ASAN_RED_ZONE_SIZE);
> data.asan_vec.safe_push (prev_offset);
> data.asan_vec.safe_push (offset);
> + /* Leave a space for alignment if STRICT_ALIGNMENT. */
> + if (STRICT_ALIGNMENT)
> + alloc_stack_frame_space ((GET_MODE_ALIGNMENT (SImode) <<
> ASAN_SHADOW_SHIFT) / BITS_PER_UNIT , 1);
>
> var_end_seq
> = asan_emit_stack_protection (virtual_stack_vars_rtx,
Re: Fix caller-save.c:add_used_regs_1 handling of pseudos
On Sun, Feb 23, 2014 at 10:14 PM, Richard Sandiford wrote: > I noticed in passing that this 4.7 cleanup: > > http://article.gmane.org/gmane.comp.gcc.patches/224853 ... > so that nothing happens for pseudos. I've no idea whether this makes > a difference in practice or not but it seems safer to restore the old > behaviour. > > Tested on mipsisa64-sde-elf rather than x86_64-linux-gnu since it only > affects reload targets. OK to install? If it's worked since GCC 4.7, why restore that code? I prefer an assert that the reg is not a pseudo. If something would break, it's still possible to restore the old behavior and have an explanation for why it should be like that. Ciao! Steven
Fix caller-save.c:add_used_regs_1 handling of pseudos
I noticed in passing that this 4.7 cleanup:
http://article.gmane.org/gmane.comp.gcc.patches/224853
changed caller-save.c:add_used_regs_1 from:
if (REG_P (x))
{
regno = REGNO (x);
if (!HARD_REGISTER_NUM_P (regno))
regno = reg_renumber[regno];
if (regno >= 0)
for (i = hard_regno_nregs[regno][GET_MODE (x)] - 1; i >= 0; i--)
SET_REGNO_REG_SET (live, regno + i);
}
return 0;
to:
if (REG_P (x))
{
regno = REGNO (x);
if (HARD_REGISTER_NUM_P (regno))
bitmap_set_range (live, regno, hard_regno_nregs[regno][GET_MODE (x)]);
else
regno = reg_renumber[regno];
}
return 0;
so that nothing happens for pseudos. I've no idea whether this makes
a difference in practice or not but it seems safer to restore the old
behaviour.
Tested on mipsisa64-sde-elf rather than x86_64-linux-gnu since it only
affects reload targets. OK to install?
Thanks,
Richard
gcc/
* caller-save.c (add_used_regs_1): Fix handling of pseudos.
Index: gcc/caller-save.c
===
--- gcc/caller-save.c 2014-01-02 22:16:03.383281697 +
+++ gcc/caller-save.c 2014-02-23 11:04:27.519785327 +
@@ -1339,7 +1339,7 @@ insert_save (struct insn_chain *chain, i
static int
add_used_regs_1 (rtx *loc, void *data)
{
- unsigned int regno;
+ int regno;
regset live;
rtx x;
@@ -1348,10 +1348,10 @@ add_used_regs_1 (rtx *loc, void *data)
if (REG_P (x))
{
regno = REGNO (x);
- if (HARD_REGISTER_NUM_P (regno))
- bitmap_set_range (live, regno, hard_regno_nregs[regno][GET_MODE (x)]);
- else
+ if (!HARD_REGISTER_NUM_P (regno))
regno = reg_renumber[regno];
+ if (regno >= 0)
+ bitmap_set_range (live, regno, hard_regno_nregs[regno][GET_MODE (x)]);
}
return 0;
}
New Swedish PO file for 'gcc' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.9-b20140202.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [C++ patch] for C++/52369
Ahem, patch resubmitted with the testsuite correctly adjusted this
time. Tested x86_64 linux, still OK to commit ?
2014-02-23 Fabien Chene
PR c++/52369
* cp/method.c (walk_field_subobs): improve the diagnostic
locations for both REFERENCE_TYPEs and non-static const members.
2014-02-23 Fabien Chene
PR c++/52369
* g++.dg/init/const10.C: New.
* g++.dg/init/const11.C: New.
* g++.dg/init/pr25811.C: Adjust.
* g++.dg/init/pr29043.C: Adjust.
* g++.dg/init/pr43719.C: Likewise.
* g++.dg/init/pr44086.C: Likewise.
* g++.dg/init/ctor4.C: Likewise.
* g++.dg/init/ctor8.C: Likewise.
* g++.dg/init/uninitialized1.C: Likewise.
--
Fabien
2014-02-06 18:04 GMT+01:00 Fabien Chêne :
> Hi,
>
> This bug seems already fixed on mainline. I have added two testcases,
> but as the C++11 one is not obvious to me, I guess this path does not
> qualify as obvious. Incidentally, while writing the C++11 testcase, I
> realized that the diagnostic was not emitted at the proper location
> and fixed it.
Index: gcc/cp/method.c
===
--- gcc/cp/method.c (révision 207406)
+++ gcc/cp/method.c (copie de travail)
@@ -1091,15 +1091,15 @@ walk_field_subobs (tree fields, tree fnn
&& default_init_uninitialized_part (mem_type))
{
if (diag)
- error ("uninitialized non-static const member %q#D",
- field);
+ error_at (DECL_SOURCE_LOCATION (field),
+ "uninitialized non-static const member %q#D", field);
bad = true;
}
else if (TREE_CODE (mem_type) == REFERENCE_TYPE)
{
if (diag)
- error ("uninitialized non-static reference member %q#D",
- field);
+ error_at (DECL_SOURCE_LOCATION (field),
+ "uninitialized non-static reference member %q#D", field);
bad = true;
}
Index: gcc/testsuite/g++.dg/init/pr44086.C
===
--- gcc/testsuite/g++.dg/init/pr44086.C (révision 207406)
+++ gcc/testsuite/g++.dg/init/pr44086.C (copie de travail)
@@ -1,9 +1,10 @@
// PR c++/44086
// { dg-do compile }
-struct A // { dg-error "uninitialized" "" { target c++11 } }
+struct A
{
int const i : 2; // { dg-message "should be initialized" "" { target c++98 } }
+ // { dg-error "uninitialized" "" { target c++11 } 6 }
};
void f()
Index: gcc/testsuite/g++.dg/init/const11.C
===
--- gcc/testsuite/g++.dg/init/const11.C (révision 0)
+++ gcc/testsuite/g++.dg/init/const11.C (révision 0)
@@ -0,0 +1,29 @@
+// PR C++/52369
+// { dg-do compile { target c++98 } }
+
+class B
+{
+ int const v_; // { dg-message "should be initialized" }
+};
+
+struct D : B {};
+
+class A
+{
+ int& ref; // { dg-message "should be initialized" }
+};
+
+struct C : A {};
+
+void f()
+{
+ D d; // { dg-error "uninitialized" }
+ new D; // { dg-error "uninitialized" }
+ D();
+ new D();
+
+ C c; // { dg-error "uninitialized" }
+ new C; // { dg-error "uninitialized" }
+ C(); // { dg-error "value-initialization" }
+ new C(); // { dg-error "value-initialization" }
+}
Index: gcc/testsuite/g++.dg/init/ctor4.C
===
--- gcc/testsuite/g++.dg/init/ctor4.C (révision 207406)
+++ gcc/testsuite/g++.dg/init/ctor4.C (copie de travail)
@@ -8,7 +8,7 @@ public:
class bar: public foo { // { dg-error "reference|bar::bar" }
private:
- int &a;
+ int &a; // { dg-error "uninitialized" "" { target c++11 } }
};
foo::foo() {
Index: gcc/testsuite/g++.dg/init/uninitialized1.C
===
--- gcc/testsuite/g++.dg/init/uninitialized1.C (révision 207406)
+++ gcc/testsuite/g++.dg/init/uninitialized1.C (copie de travail)
@@ -1,8 +1,8 @@
// PR c++/58126
-struct A { // { dg-error "uninitialized" "" { target c++11 } }
- const int value1;
- int& value2;
+struct A {
+ const int value1; // { dg-error "uninitialized.*const" "" { target c++11 } }
+ int& value2; // { dg-error "uninitialized.*reference" "" { target c++11 } }
};
struct B : A { }; // { dg-error "deleted" "" { target c++11 } }
Index: gcc/testsuite/g++.dg/init/pr43719.C
===
--- gcc/testsuite/g++.dg/init/pr43719.C (révision 207406)
+++ gcc/testsuite/g++.dg/init/pr43719.C (copie de travail)
@@ -1,51 +1,62 @@
// PR c++/43719
// { dg-do compile }
-struct A1 // { dg-error "uninitialized" "" { target c++11 } }
+struct A1
{
int const j; // { dg-message "should be initialized" "" { target c++98 } }
+ // { dg-error "uninitialized" "" { target c++11 } 6 }
};
-struct A2 // { dg-error "uninitialized" "" { target c++11 } }
+struct A2
{
int const volatile i; // { dg-message "should be initialized" "" { target c++98 } }
+ // { dg-error "uninitialized" "" { target c++11 } 12 }
Re: [Patch, microblaze]: Correct names of shift instructions
On 11/25/13 23:53, David Holsgrove wrote: Existing MicroBlaze shift instruction pattern names don't match surrounding format. ashlri_reg should be ashrsi_reg - arithmetic shift right for SI mode lshlri_reg should be lshrsi_reg - logical shift right for SI mode Changelog 2013-11-26 David Holsgrove * gcc/config/microblaze/microblaze.md: Correct ashrsi_reg / lshrsi_reg names. gcc-head: Committed revision 208061. gcc-4_8_branch: Committed revision 208062. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Branch Compare unroll loops
On 11/25/13 23:53, David Holsgrove wrote: Hi Michael, I've attached patch based on latest gcc master. Please apply when ready. Changelog 2013-11-26 David Holsgrove * gcc/config/microblaze/predicates.md: Add cmp_op predicate. * gcc/config/microblaze/microblaze.md: Add branch_compare instruction which uses cmp_op predicate and emits cmp insn before branch. * gcc/config/microblaze/microblaze.c (microblaze_emit_compare): Rename to microblaze_expand_conditional_branch and consolidate logic. (microblaze_expand_conditional_branch): emit branch_compare insn instead of handling cmp op separate from branch insn. thanks, David On 15 July 2013 14:58, David Holsgrove wrote: To facilitate optimization pass understanding of the conditional branch for microblaze, remove the UNSPEC'd signed_compare / unsigned_compare instructions, and replace with a complete branch_compare which will output_asm_insn the correct cmp/cmpu depending on comparison code and signed / unsigned. We then return the correct branch instruction. cbranchsi now calls an expanded microblaze_expand_conditional_branch function which will carry out compare against zero, compare EQ/NE, and all other compares appropriately. -funroll-loops optimization pass can now proceed Changelog 2013-07-15 David Holsgrove * gcc/config/microblaze/predicates.md: Add cmp_op predicate. * gcc/config/microblaze/microblaze.md: Add branch_compare instruction which uses cmp_op predicate and emits cmp insn before branch. * gcc/config/microblaze/microblaze.c (microblaze_emit_compare): Rename to microblaze_expand_conditional_branch and consolidate logic. (microblaze_expand_conditional_branch): emit branch_compare insn instead of handling cmp op separate from branch insn. thanks, David gcc-head: Committed revision 208055. gcc-4_8_branch: Committed revision 208056. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Remove SECONDARY_MEMORY_NEEDED
On 02/14/14 09:42, Michael Eager wrote: On 02/13/14 21:48, David Holsgrove wrote: Hi Michael, List, -Original Message- From: David Holsgrove Sent: Wednesday, 22 January 2014 1:43 pm To: 'Michael Eager'; gcc-patches@gcc.gnu.org Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala Subject: RE: [Patch, microblaze]: Remove SECONDARY_MEMORY_NEEDED Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Friday, 17 January 2014 4:44 am To: David Holsgrove; gcc-patches@gcc.gnu.org Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch, microblaze]: Remove SECONDARY_MEMORY_NEEDED On 11/25/13 23:51, David Holsgrove wrote: Hi Michael, I've attached patch based on latest gcc master. Please let me know if you need anything further. thanks, David On 15 July 2013 14:44, David Holsgrove wrote: Hi Michael, On 18 March 2013 22:49, David Holsgrove wrote: MicroBlaze doesn't have restrictions that would force us to reload regs via memory. Don't define SECONDARY_MEMORY_NEEDED. Fixes an ICE when compiling OpenSSL for linux. Changelog 2013-03-18 Edgar E. Iglesias * gcc/config/microblaze/microblaze.h: Remove SECONDARY_MEMORY_NEEDED definition. Signed-off-by: Edgar E. Iglesias Signed-off-by: Peter A. G. Crosthwaite Patch remains the same, please apply when ready. thanks, David Hi David -- Is it possible to add a test case which shows the ICE? I'm afraid I don’t still have my test environment for this patch from last March, I'll attempt to recreate and distil into a small test case if possible, based on the error encountered whilst building openssl. I'll update again when I have some further detail. I've managed to recreate the original internal compiler error whilst building openssl with microblazeel linux toolchain. I've reduced the error down to the attached testcase. It is taken directly from openssl (with no dependencies on openssl headers), so I'm unsure of the suitability of this test both technically and license wise for inclusion in gcc. Changelog entry would be; 2013-03-18 Edgar E. Iglesias * gcc/config/microblaze/microblaze.h: Remove SECONDARY_MEMORY_NEEDED definition. ChangeLog/testsuite 2014-02-13 David Holsgrove * gcc/testsuite/gcc.target/microblaze/others/mem_reload.c: New test. thanks, David Thanks. gcc-head: Committed revision 208059. gcc-4_8_branch: Committed revision 208060. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 02/14/14 09:41, Michael Eager wrote:
On 02/13/14 21:48, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Sunday, 26 January 2014 1:57 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui
Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to
support varargs thunk
On 07/14/13 21:37, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Saturday, 13 July 2013 9:33 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui
Subject: Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to
support varargs thunk
On 03/18/13 05:49, David Holsgrove wrote:
Changelog
2013-03-18 David Holsgrove
* gcc/config/microblaze/microblaze.c: Add
microblaze_asm_output_mi_thunk
and define TARGET_ASM_OUTPUT_MI_THUNK and
TARGET_ASM_CAN_OUTPUT_MI_THUNK
Sorry it has taken so long to review this patch.
[--snip--]
2013-07-15 David Holsgrove
* gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk
and define TARGET_ASM_OUTPUT_MI_THUNK and
TARGET_ASM_CAN_OUTPUT_MI_THUNK
This patch causes a number of regressions in the G++ test suite.
For example, abi/covariant{3,4,5}.C, abi/vcall1.C,
inherit/covariant{1,2,3,4,17,18}.C,
inherit/thunk{7,10}.C and others.
Apologies - this patch was originally written in 2012 and submitted to this
list a year ago.
It has not been reviewed or tested for regressions in 12 months, and has taken
me a bit of time to
go back to the original work and rerun the testsuite as it stands today.
Please find attached updated patch which has no regressions. I believe the
testcase which checks
the functionality of this patch is ' g++.old-deja/g++.jason/thunk3.C'
Changelog entry remains the same since March 2013.
Thanks.
gcc-head: Committed revision 208057.
gcc-4_8_branch: Committed revision 208058.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[PATCH,rs6000,committed] Loosen assert in rs6000_emit_le_vsx_move
Hi,
There's an assert in rs6000_emit_le_vsx_move () that was correct for
-mcpu=power7, but with the TImode changes for Power8, we can trigger the
assert with -mcpu=power8 on little endian. We can now see a dest rtx
that is a vector subreg of TImode. Allowing for this in the assert
fixes a failure in the test suite.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Committed as obvious.
Thanks,
Bill
2014-02-23 Bill Schmidt
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_move): Relax assert
to permit subregs.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 208050)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -8040,7 +8040,7 @@ rs6000_emit_le_vsx_move (rtx dest, rtx source, enu
if (MEM_P (source))
{
- gcc_assert (REG_P (dest));
+ gcc_assert (REG_P (dest) || GET_CODE (dest) == SUBREG);
rs6000_emit_le_vsx_load (dest, source, mode);
}
else
[Ada] bypass more VCEs in build_simple_component_ref
This is not really a regression but, in the light of the recent discussion
about VIEW_CONVERT_EXPRs, I think this is worth having in 4.9: we can fold
more VIEW_CONVERT_EXPRs internally generated in gigi.
Tested on x86_64-suse-linux, applied on the mainline.
2014-02-23 Eric Botcazou
* gcc-interface/utils2.c (build_simple_component_ref): Fix formatting.
Look through a conversion between original and packable version to get
the base object.
(build_component_ref): Rework comment and fix formatting.
--
Eric BotcazouIndex: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c (revision 208040)
+++ gcc-interface/utils2.c (working copy)
@@ -1897,11 +1897,11 @@ gnat_build_constructor (tree type, vec *elts = CONSTRUCTOR_ELTS (record_variable);
+ vec *elts = CONSTRUCTOR_ELTS (base);
unsigned HOST_WIDE_INT idx;
tree index, value;
FOR_EACH_CONSTRUCTOR_ELT (elts, idx, index, value)
@@ -2022,16 +2045,15 @@ build_simple_component_ref (tree record_
return fold (ref);
}
-/* Like build_simple_component_ref, except that we give an error if the
- reference could not be found. */
+/* Likewise, but generate a Constraint_Error if the reference could not be
+ found. */
tree
-build_component_ref (tree record_variable, tree component,
- tree field, bool no_fold_p)
+build_component_ref (tree record_variable, tree component, tree field,
+ bool no_fold_p)
{
tree ref = build_simple_component_ref (record_variable, component, field,
no_fold_p);
-
if (ref)
return ref;
Re: [PATCH,rs6000] Add -maltivec=be support for vec_lde and vec_ste
On Sat, Feb 22, 2014 at 10:25 PM, Bill Schmidt
wrote:
> Hi,
>
> This patch adds -maltivec=be support for vec_lde and vec_ste, similarly
> to what was done for vec_ld, vec_st, vec_ldl, and vec_stl. Much of the
> same infrastructure is used. Because the insn pattern for vec_ste is
> formed slightly differently than the ones for vec_st and vec_stl, we
> can't reuse altivec_expand_stvx_be in this case (but
> altivec_expand_lvx_be works fine for vec_lde). There are four new test
> cases, covering correct behavior for all appropriate vector types for
> BE, LE, and LE with -maltivec=be.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions. Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> gcc:
>
> 2014-02-22 Bill Schmidt
>
> * config/rs6000/altivec.md (altivec_lvex): Replace
> define_insn with define_expand and new define_insn
> *altivec_lvex_internal.
> (altivec_stvex): Replace define_insn with define_expand
> and new define_insn *altivec_stvex_internal.
> * config/rs6000/rs6000-protos.h (altivec_expand_stvex_be): New
> prototype.
> * config/rs6000/rs6000.c (altivec_expand_lvx_be): Document use by
> lve*x built-ins.
> (altivec_expand_stvex_be): New function.
>
> gcc/testsuite:
>
> 2014-02-22 Bill Schmidt
>
> * testsuite/gcc.dg/vmx/lde.c: New test.
> * testsuite/gcc.dg/vmx/lde-be-order.c: New test.
> * testsuite/gcc.dg/vmx/ste.c: New test.
> * testsuite/gcc.dg/vmx/ste-be-order.c: New test.
Okay.
Thanks, David
Re: [v3] complex functions with expression template reals
On Sun, 23 Feb 2014, Paolo Carlini wrote: On 02/23/2014 11:32 AM, Marc Glisse wrote: Hello, looking at this question: http://stackoverflow.com/q/21737186/1918193 I was surprised to see that libstdc++'s std::complex basically just works with user-defined types, even weird expression template ones, although that's not a supported use afaik. The only functions that fail seem to be exp and pow, both because they call polar with two arguments that have different (expression) types. I am not proposing to make this a supported use, but the cost of this small patch seems very low, and if it makes a couple users happy... Regtested with no problem on x86_64-linux-gnu, ok for stage 1? I would even be in favor of applying it now. Can we figure out simple (ie, not relying on boost...) testcases too? I didn't try std::complex>, maybe... Otherwise, you need a type T with all the (real) math functions defined, and where every operation returns a different type (implicitly convertible to T). And then you want to call all the complex functions. That seems doable, but way bigger than I'm willing to go for this feature. If you want to take over, be my guest ;-) -- Marc Glisse
Re: [v3] complex functions with expression template reals
On 02/23/2014 11:32 AM, Marc Glisse wrote: Hello, looking at this question: http://stackoverflow.com/q/21737186/1918193 I was surprised to see that libstdc++'s std::complex basically just works with user-defined types, even weird expression template ones, although that's not a supported use afaik. The only functions that fail seem to be exp and pow, both because they call polar with two arguments that have different (expression) types. I am not proposing to make this a supported use, but the cost of this small patch seems very low, and if it makes a couple users happy... Regtested with no problem on x86_64-linux-gnu, ok for stage 1? I would even be in favor of applying it now. Can we figure out simple (ie, not relying on boost...) testcases too? Paolo.
[PATCH] Fix fortran/pr60236
Hi, the test case gfortran.dg/vect/pr32380.f was found to fail on armv7l-unknown-linux-gnueabihf. The reason for this is that one out of 6 loops does not get vectorized, because this target does not support a vectorization of sqrtf. The same test case is known to fail on powerpc-apple-darwin9 due to a different reason, see PR52229. On that target 5 out of 6 loops do not get vectorized, because of an alignment issue. That was solved at that time by declaring some targets xfail. This patch tries to solve the problem in a more general way, by classifying the target's expected result by using vect_element_align and vect_call_sqrtf attributes. This patch has been tested on armv7l-unknown-linux-gnueabihf, x86_64-unknown-linux-gnu and powerpc-apple-darwin9. OK for trunk? Regards Bernd. P.S.: Many thanks to Dominique d'Humieres for reg-testing on powerpc-apple-darwin9. patch-pr60236.diff Description: Binary data
builtin fe[gs]etround
Hello,
a natural first step to optimize changes of rounding modes seems to be
making these 2 functions builtins. I don't know exactly how far
optimizations will be able to go (the fact that fesetround can fail
complicates things a lot). What is included here:
1) fegetround is pure.
2) Neither function aliases (use or clobber) any memory. I expect this is
likely not true on all platforms, some probably store the rounding mode in
a global variable that is accessible through other means (though mixing
direct accesses with calls to fe*etround seems a questionable style). Any
opinion or advice here?
Regtested on x86_64-linux-gnu, certainly not for 4.9.
2014-02-23 Marc Glisse
gcc/
* builtins.def (BUILT_IN_FEGETROUND, BUILT_IN_FESETROUND): Add.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
call_may_clobber_ref_p_1): Handle them.
gcc/testsuite/
* gcc.dg/tree-ssa/fegsetround.c: New file.
--
Marc GlisseIndex: gcc/builtins.def
===
--- gcc/builtins.def(revision 208045)
+++ gcc/builtins.def(working copy)
@@ -276,20 +276,22 @@ DEF_C99_BUILTIN(BUILT_IN_EXPM1F,
DEF_C99_BUILTIN(BUILT_IN_EXPM1L, "expm1l",
BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_LIB_BUILTIN(BUILT_IN_FABS, "fabs", BT_FN_DOUBLE_DOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSF, "fabsf", BT_FN_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN(BUILT_IN_FABSD128, "fabsd128",
BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_FDIM, "fdim", BT_FN_DOUBLE_DOUBLE_DOUBLE,
ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_BUILTIN(BUILT_IN_FDIMF, "fdimf", BT_FN_FLOAT_FLOAT_FLOAT,
ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_BUILTIN(BUILT_IN_FDIML, "fdiml",
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
+DEF_C99_BUILTIN(BUILT_IN_FEGETROUND, "fegetround", BT_FN_INT,
ATTR_PURE_NOTHROW_LEAF_LIST)
+DEF_C99_BUILTIN(BUILT_IN_FESETROUND, "fesetround", BT_FN_INT_INT,
ATTR_NOTHROW_LEAF_LIST)
DEF_LIB_BUILTIN(BUILT_IN_FLOOR, "floor", BT_FN_DOUBLE_DOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_C90RES_BUILTIN (BUILT_IN_FLOORF, "floorf", BT_FN_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_C90RES_BUILTIN (BUILT_IN_FLOORL, "floorl",
BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_FMA, "fma",
BT_FN_DOUBLE_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING)
DEF_C99_BUILTIN(BUILT_IN_FMAF, "fmaf", BT_FN_FLOAT_FLOAT_FLOAT_FLOAT,
ATTR_MATHFN_FPROUNDING)
DEF_C99_BUILTIN(BUILT_IN_FMAL, "fmal",
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING)
DEF_C99_BUILTIN(BUILT_IN_FMAX, "fmax", BT_FN_DOUBLE_DOUBLE_DOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_FMAXF, "fmaxf", BT_FN_FLOAT_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_FMAXL, "fmaxl",
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_C99_BUILTIN(BUILT_IN_FMIN, "fmin", BT_FN_DOUBLE_DOUBLE_DOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
Index: gcc/testsuite/gcc.dg/tree-ssa/fegsetround.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/fegsetround.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/fegsetround.c (working copy)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c99 -O -fdump-tree-optimized" } */
+
+#include
+
+int a;
+int f ()
+{
+ a = 42;
+ // don't read a
+ int x = fegetround ();
+ fesetround (x + 1);
+ a = 0;
+ return a;
+}
+int g ()
+{
+ a = 0;
+ // don't write a
+ int x = fegetround ();
+ fesetround (x + 1);
+ return a;
+}
+int h ()
+{
+ // pure
+ return fegetround () - fegetround ();
+}
+
+/* { dg-final { scan-tree-dump-times "return 0" 3 "optimized" } } */
+/* { dg-final { scan-tree-dump-not "a = 42" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Property changes on: gcc/testsuite/gcc.dg/tree-ssa/fegsetround.c
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 208045)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -1537,20 +1537,22 @@ ref_maybe_used_by_call_p_1 (gimple call,
[v3] complex functions with expression template reals
Hello,
looking at this question:
http://stackoverflow.com/q/21737186/1918193
I was surprised to see that libstdc++'s std::complex basically just works
with user-defined types, even weird expression template ones, although
that's not a supported use afaik.
The only functions that fail seem to be exp and pow, both because they
call polar with two arguments that have different (expression) types.
I am not proposing to make this a supported use, but the cost of this
small patch seems very low, and if it makes a couple users happy...
Regtested with no problem on x86_64-linux-gnu, ok for stage 1?
2014-02-23 Marc Glisse
* include/std/complex (__complex_exp, pow): Specify the template
parameter in calls to std::polar, for expression templates.
--
Marc GlisseIndex: libstdc++-v3/include/std/complex
===
--- libstdc++-v3/include/std/complex(revision 208045)
+++ libstdc++-v3/include/std/complex(working copy)
@@ -728,21 +728,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#else
template
inline complex<_Tp>
cosh(const complex<_Tp>& __z) { return __complex_cosh(__z); }
#endif
// 26.2.8/3 exp(__z): Returns the complex base e exponential of x
template
inline complex<_Tp>
__complex_exp(const complex<_Tp>& __z)
-{ return std::polar(exp(__z.real()), __z.imag()); }
+{ return std::polar<_Tp>(exp(__z.real()), __z.imag()); }
#if _GLIBCXX_USE_C99_COMPLEX
inline __complex__ float
__complex_exp(__complex__ float __z) { return __builtin_cexpf(__z); }
inline __complex__ double
__complex_exp(__complex__ double __z) { return __builtin_cexp(__z); }
inline __complex__ long double
__complex_exp(const __complex__ long double& __z)
@@ -988,21 +988,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
pow(const complex<_Tp>& __x, const _Tp& __y)
{
#ifndef _GLIBCXX_USE_C99_COMPLEX
if (__x == _Tp())
return _Tp();
#endif
if (__x.imag() == _Tp() && __x.real() > _Tp())
return pow(__x.real(), __y);
complex<_Tp> __t = std::log(__x);
- return std::polar(exp(__y * __t.real()), __y * __t.imag());
+ return std::polar<_Tp>(exp(__y * __t.real()), __y * __t.imag());
}
template
inline complex<_Tp>
__complex_pow(const complex<_Tp>& __x, const complex<_Tp>& __y)
{ return __x == _Tp() ? _Tp() : std::exp(__y * std::log(__x)); }
#if _GLIBCXX_USE_C99_COMPLEX
inline __complex__ float
__complex_pow(__complex__ float __x, __complex__ float __y)
@@ -1025,22 +1025,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline complex<_Tp>
pow(const complex<_Tp>& __x, const complex<_Tp>& __y)
{ return __complex_pow(__x, __y); }
#endif
template
inline complex<_Tp>
pow(const _Tp& __x, const complex<_Tp>& __y)
{
- return __x > _Tp() ? std::polar(pow(__x, __y.real()),
- __y.imag() * log(__x))
+ return __x > _Tp() ? std::polar<_Tp>(pow(__x, __y.real()),
+ __y.imag() * log(__x))
: std::pow(complex<_Tp>(__x), __y);
}
/// 26.2.3 complex specializations
/// complex specialization
template<>
struct complex
{
typedef float value_type;
typedef __complex__ float _ComplexT;
Re: [PATCH] Fix PR c++/60065.
On 2014-02-21 15:49, Jason Merrill wrote: On 02/21/2014 03:19 AM, Adam Butcher wrote: Jason Merrill wrote: Why doesn't num_template_parameter_lists work as a predicate here? It works in the lambda case as it is updated there, but for generic functions I think the following prevents it: cp/parser.c:17063: Hmm, I wonder what that's for? What breaks when you remove it? :) Nothing (according to the g++.dg testsuite at least). It's been there since I started looking at GCC so I assumed that it was needed for something. Having removed it I should be able use a num_template_parameter_lists and template_class_depth as you suggested to solve this issue (hopefully without the need of a scope walk). Cheers, Adam
