[Ada] Small tweak to gigi
This moves the initialization of the linemap up to before the first assertion
at the beginning of the gigi routine. As experienced under PR ada/49084, if
the assertion fails and the linemap isn't initialized yet, things can go awry.
Tested on i586-suse-linux, applied on the mainline.
2011-12-11 Eric Botcazou ebotca...@adacore.com
* gcc-interface/trans.c (gigi): Initialize the linemap earlier.
--
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 182102)
+++ gcc-interface/trans.c (working copy)
@@ -297,13 +297,6 @@ gigi (Node_Id gnat_root, int max_gnat_no
type_annotate_only = (gigi_operating_mode == 1);
- gcc_assert (Nkind (gnat_root) == N_Compilation_Unit);
-
- /* Declare the name of the compilation unit as the first global
- name in order to make the middle-end fully deterministic. */
- t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
- first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
-
for (i = 0; i number_file; i++)
{
/* Use the identifier table to make a permanent copy of the filename as
@@ -328,6 +321,13 @@ gigi (Node_Id gnat_root, int max_gnat_no
linemap_add (line_table, LC_LEAVE, 0, NULL, 0);
}
+ gcc_assert (Nkind (gnat_root) == N_Compilation_Unit);
+
+ /* Declare the name of the compilation unit as the first global
+ name in order to make the middle-end fully deterministic. */
+ t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
+ first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
+
/* Initialize ourselves. */
init_code_table ();
init_gnat_to_gnu ();
Re: [patch, fortran] Fix PR 50690
On Sun, Dec 11, 2011 at 11:11:28AM +0100, Thomas Koenig wrote: @@ -1330,16 +1345,38 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code WALK_SUBEXPR (co-ext.dt-extra_comma); break; - case EXEC_OMP_DO: + in_omp_workshare = true; + + break; + What is the above hunk? Looks like unreachable code: break; in_omp_workshare = true; break; Other than that looks good to me. Jakub
[Ada] Assertion to detect conflicting alignments in renaming
As suggested by Robert, it would be valuable to have an assertion in gigi to
detect conflicting alignments in renaming, i.e. when an alignment value set on
the renaming cannot be honored because the renamed object isn't sufficiently
aligned.
Tested on i586-suse-linux, applied on the mainline.
2011-12-11 Eric Botcazou ebotca...@adacore.com
* gcc-interface/decl.c (gnat_to_gnu_entity) object: If there is an
alignment set on a renaming, assert that the renamed object is aligned
enough as to make it possible to honor it.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 182102)
+++ gcc-interface/decl.c (working copy)
@@ -1008,6 +1008,17 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
saved = true;
annotate_object (gnat_entity, gnu_type, NULL_TREE,
false, false);
+ /* This assertion will fail if the renamed object
+ isn't aligned enough as to make it possible to
+ honor the alignment set on the renaming. */
+ if (align)
+ {
+ unsigned int renamed_align
+ = DECL_P (gnu_decl)
+? DECL_ALIGN (gnu_decl)
+: TYPE_ALIGN (TREE_TYPE (gnu_decl));
+ gcc_assert (renamed_align = align);
+ }
break;
}
[Ada] Leverage 6.2(12) to restrict parameter aliasing
The 6.2(12) paragraph reads:
If one name denotes a part of a formal parameter, and a second name denotes
a part of a distinct formal parameter or an object that is not part of a
formal parameter, then the two names are considered distinct access paths. If
an object is of a type for which the parameter passing mechanism is not
specified, then it is a bounded error to assign to the object via one access
path, and then read the value of the object via a distinct access path, unless
the first access path denotes a part of a formal parameter that no longer
exists at the point of the second access (due to leaving the corresponding
callable construct). The possible consequences are that Program_Error is
raised, or the newly assigned value is read, or some old value of the object
is read.
We leverage it to consider that parameters passed by reference at the sole
decision of the compiler are restrict-qualified in the C sense.
Tested on i586-suse-linux, applied on the mainline.
2011-12-11 Eric Botcazou ebotca...@adacore.com
* gcc-interface/decl.c (gnat_to_gnu_param): Set the restrict qualifier
on references built for parameters which aren't specifically by-ref.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 182201)
+++ gcc-interface/decl.c (working copy)
@@ -5518,7 +5518,15 @@ gnat_to_gnu_param (Entity_Id gnat_param,
|| (!foreign
default_pass_by_ref (gnu_param_type)
{
+ /* We take advantage of 6.2(12) by considering that references built for
+ parameters whose type isn't by-ref and for which the mechanism hasn't
+ been forced to by-ref are restrict-qualified in the C sense. */
+ bool restrict_p
+ = !TREE_ADDRESSABLE (gnu_param_type) mech != By_Reference;
gnu_param_type = build_reference_type (gnu_param_type);
+ if (restrict_p)
+ gnu_param_type
+ = build_qualified_type (gnu_param_type, TYPE_QUAL_RESTRICT);
by_ref = true;
/* In some ABIs, e.g. SPARC 32-bit, fat pointer types are themselves
[Ada] Fix small elaboration regression
We now generate elaboration code to initialize an aggregate that contains a
null access-to-unconstrained-array value.
Fixed thusly, tested on i586-suse-linux, applied on the mainline.
2011-12-11 Eric Botcazou ebotca...@adacore.com
* gcc-interface/utils2.c (gnat_build_constructor): Test the TREE_STATIC
flag of elements to compute that of the constructor.
2011-12-11 Eric Botcazou ebotca...@adacore.com
* gnat.dg/specs/elab3.ads: New test.
--
Eric Botcazou
Index: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c (revision 182102)
+++ gcc-interface/utils2.c (working copy)
@@ -1817,7 +1817,7 @@ gnat_build_constructor (tree type, VEC(c
FOR_EACH_CONSTRUCTOR_ELT (v, n_elmts, obj, val)
{
/* The predicate must be in keeping with output_constructor. */
- if (!TREE_CONSTANT (val)
+ if ((!TREE_CONSTANT (val) !TREE_STATIC (val))
|| (TREE_CODE (type) == RECORD_TYPE
CONSTRUCTOR_BITFIELD_P (obj)
!initializer_constant_valid_for_bitfield_p (val))
-- { dg-do compile }
pragma Restrictions(No_Elaboration_Code);
package Elab3 is
type T_List is array (Positive range ) of Integer;
type T_List_Access is access constant T_List;
type R is record
A : T_List_Access;
end record;
C : constant R := (A = null);
end Elab3;
Re: [PATCH 5/6] mips: Implement vec_perm_const.
[Mingjie, please could you help with the Loongson question near the end?]
Richard Henderson r...@redhat.com writes:
@@ -89,61 +89,102 @@
DONE;
})
-; pul.ps - Pair Upper Lower
-(define_insn mips_pul_ps
+(define_insn vec_perm_const_ps
[(set (match_operand:V2SF 0 register_operand =f)
- (vec_merge:V2SF
- (match_operand:V2SF 1 register_operand f)
- (match_operand:V2SF 2 register_operand f)
- (const_int 2)))]
+ (vec_select:V2SF
+ (vec_concat:V4SF
+ (match_operand:V2SF 1 register_operand f)
+ (match_operand:V2SF 2 register_operand f))
+ (parallel [(match_operand:SI 3 const_0_or_1_operand )
+ (match_operand:SI 4 const_2_or_3_operand )])))]
TARGET_HARD_FLOAT TARGET_PAIRED_SINGLE_FLOAT
- pul.ps\t%0,%1,%2
+{
+ static const int * const mnemonics[2][4] = {
+/* LE */ { pll.ps\t%0,%2,%1, pul.ps\t%0,%2,%1,
+plu.ps\t%0,%2,%1, puu.ps\t%0,%2,%1 },
+/* BE */ { puu.ps\t%0,%1,%2, plu.ps\t%0,%1,%2,
+pul.ps\t%0,%1,%2, pll.ps\t%0,%1,%2 },
+ };
+
+ unsigned mask = INTVAL (operands[3]) * 2 + (INTVAL (operands[4]) - 2);
+ return mnemonics[WORDS_BIG_ENDIAN][mask];
+}
So I stared at this for fully an hour trying to work out all the
various orderings (vec_concat operands always in memory order,
parallel selector always in memory order, GCC vector element 0
being upper on big-endian and lower on little-endian,
P??.PS always specifying the upper part of the result first, etc.).
I ended up with:
/* Let opL be the lower part of operand op and opU be the upper part.
The P[UL][UL].PS instruction always specifies the upper part of the
result first, so the instruction is:
PaULbUL.PS %0,aop,bop
where 0U == aopaUL and 0L == bopbUL.
GCC's vector indices are specified in memory order, which means
that vector element 0 is the lower part (L) on little-endian targets
and the upper part (U) on big-endian targets. vec_concat likewise
concatenates in memory order, which means that operand 3 (being
0 or 1) selects part of operand 1 and operand 4 (being 2 or 3)
selects part of operand 2.
Let:
I3 = INTVAL (operands[3])
I4 = INTVAL (operands[4]) - 2
Taking the two endiannesses in turn:
Little-endian:
The semantics of the RTL pattern are:
{ 0L, 0U } = { X[I3], X[I4 + 2] }, where X = { 1L, 1U, 2L, 2U }
so: 0L = { 1L, 1U }[I3] (= bopbUL)
0U = { 2L, 2U }[I4] (= aopaUL)
aop = 2, aUL = I4 ? U : L
bop = 1, bUL = I3 ? U : L
[LL] !I4 !I3 [UL] I4 !I3
[LU] !I4 I3[UU] I4 I3
Big-endian:
The semantics of the RTL pattern are:
{ 0U, 0L } = { X[I3], X[I4 + 2] }, where X = { 1U, 1L, 2U, 2L }
so: 0U = { 1U, 1L }[I3] (= aopaUL)
0L = { 2U, 2L }[I4] (= bopbUL)
aop = 1, aUL = I3 ? L : U
bop = 2, bUL = I4 ? L : U
[UU] !I3 !I4 [UL] !I3 I4
[LU] I3 !I4[LL] I3 I4. */
which suggests that the PUL and PLU entries for big-endian should be
the other way around. Does that sound right, or have I misunderstood?
(Also, const char * rather than const int *.)
The same confusion hit me with the expanders:
+(define_expand mips_pul_ps
+ [(match_operand:V2SF 0 register_operand )
+ (match_operand:V2SF 1 register_operand )
+ (match_operand:V2SF 2 register_operand )]
+ TARGET_HARD_FLOAT TARGET_PAIRED_SINGLE_FLOAT
+{
+ if (WORDS_BIG_ENDIAN)
+emit_insn (gen_vec_perm_const_ps (operands[0], operands[1], operands[2],
+ const0_rtx, const2_rtx));
+ else
+emit_insn (gen_vec_perm_const_ps (operands[0], operands[2], operands[1],
+ const1_rtx, GEN_INT (3)));
+ DONE;
+})
This one looks like a pasto: the operands given here are the same
as for mips_puu_ps. But...
+(define_expand mips_plu_ps
+ [(match_operand:V2SF 0 register_operand )
+ (match_operand:V2SF 1 register_operand )
+ (match_operand:V2SF 2 register_operand )]
+ TARGET_HARD_FLOAT TARGET_PAIRED_SINGLE_FLOAT
+{
+ if (WORDS_BIG_ENDIAN)
+emit_insn (gen_vec_perm_const_ps (operands[0], operands[1], operands[2],
+ const1_rtx, const2_rtx));
+ else
+emit_insn (gen_vec_perm_const_ps (operands[0], operands[2], operands[1],
+ const0_rtx, GEN_INT (3)));
+ DONE;
+})
...for little-endian, we need to pass the U and L components of the
mnemonic in the reverse order: the MIPS instruction specifies the upper
part first, whereas the rtl pattern specifies the lower part first.
And for little-endian, U refers to memory element 1 and L to memory
element 0. So I think this should be:
if (WORDS_BIG_ENDIAN)
emit_insn (gen_vec_perm_const_ps (operands[0], operands[1], operands[2],
Re: [patch, fortran] Fix PR 50690
Thomas Koenig wrote: Regression-tested. OK for trunk (finally)? Looks also OK from my side - except for the left over which Jakub has already noticed. I think the following lines can be simply removed: - case EXEC_OMP_DO: + in_omp_workshare = true; + + break; + Tobias PS: If you have time, can you also backport the patch for PR 51338 to the 4.6 branch?
Re: [committed] Another 4.6 backport (PR tree-optimization/50078)
Jakub Jelinek writes: Hi! Bootstrapped/regtested on x86_64-linux and i686-linux, committed to 4.6 branch. 2011-12-09 Jakub Jelinek ja...@redhat.com Backport from mainline 2011-12-08 Jakub Jelinek ja...@redhat.com PR tree-optimization/51466 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Also copy TREE_SIDE_EFFECTS. * gcc.c-torture/execute/pr51466.c: New test. 2011-11-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/50078 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Copy over TREE_THIS_VOLATILE also from the old to new lhs resp. rhs. * gcc.dg/pr50078.c: New test. This patch, r182157 on 4.6 branch, caused a test suite regression on arm-linux-gnueabi: +FAIL: gcc.dg/pr45819.c (test for excess errors) because the compiler now emits the following warning: pr45819.c: In function 'ehci_hub_control': pr45819.c:16:10: warning: mis-aligned access used for structure member [-fstrict-volatile-bitfields] pr45819.c:16:10: note: when a volatile object spans multiple type-sized locations, the compiler must choose between using a single mis-aligned access to preserve the volatility, or using multiple aligned accesses to avoid runtime faults; this code may fail at runtime if the hardware does not allow this access I believe the warning is correct, so perhaps the warning should just be suppressed in pr45819.c with -w. Trunk also has this issue. /Mikael
Re: [committed] 4 backports from trunk to 4.6 branch
Jakub Jelinek writes: Hi! Bootstrapped/regtested on x86_64-linux and i686-linux, committed to 4.6 branch: ... 2011-12-08 Jakub Jelinek ja...@redhat.com Backport from mainline 2011-12-05 Jakub Jelinek ja...@redhat.com Eric Botcazou ebotca...@adacore.com PR middle-end/51323 PR middle-end/50074 * calls.c (internal_arg_pointer_exp_state): New variable. (internal_arg_pointer_based_exp_1, internal_arg_pointer_exp_scan): New functions. (internal_arg_pointer_based_exp): New function. (mem_overlaps_already_clobbered_arg_p): Use it. (expand_call): Free internal_arg_pointer_exp_state.cache vector and clear internal_arg_pointer_exp_state.scan_start. 2011-11-26 Joern Rennecke joern.renne...@embecosm.com PR middle-end/50074 * calls.c (mem_overlaps_already_clobbered_arg_p): Return false if no outgoing arguments have been stored so far. 2011-12-05 Jakub Jelinek ja...@redhat.com Eric Botcazou ebotca...@adacore.com PR middle-end/51323 PR middle-end/50074 * gcc.c-torture/execute/pr51323.c: New test. This patch, r182112 on 4.6 branch, caused a test suite regression on arm-linux-gnueabi: +FAIL: gcc.c-torture/execute/20050713-1.c compilation, -O2 (internal compiler error) +UNRESOLVED: gcc.c-torture/execute/20050713-1.c execution, -O2 +FAIL: gcc.c-torture/execute/20050713-1.c compilation, -Os (internal compiler error) +UNRESOLVED: gcc.c-torture/execute/20050713-1.c execution, -Os because the compiler now ICEs: 20050713-1.c: In function 'bar3': 20050713-1.c:38:3: internal compiler error: in calculate_allocation, at vec.c:183 The same ICE also happens with today's trunk. /Mikael
Re: [PATCH 5/6] mips: Implement vec_perm_const.
On Sun, 11 Dec 2011, Richard Sandiford wrote:
[Mingjie, please could you help with the Loongson question near the end?]
As H-P mentioned, this changes the __builtin_* interface for the PSHUFH
intrinsics. These intrinsics are supposed to be used via the inline
wrappers in loongson.h, so we can either keep the unused argument in
the pshufh_{u,s} or, as H-P suggests, remove the argument from both.
I don't know which is better. loongson.h needs to change either way,
so in the patch below, I went for the former. The latter would need
testsuite changes too. Mingjie, which do you think is best?
Please also consider incrementing __mips_loongson_vector_rev, or
if currently empty, set to 1. And mention PR48068 in the
changelog; fixed in part.
(I can't see what builtin_define does, set it to 1 or just defined?)
brgds, H-P
[C++ Patch] for c++/14258 (aka using typename)
Hi, Here, we weren't creating a typename_type for a dependent type introduced by a using declaration. A USING_DECL was not recording the fact that it refers to a dependent type, so I've created a new macro USING_DECL_TYPENAME_P to record that information (using the free slot DECL_LANG_FLAG_1 for USING_DECLs), and set it appropriately in cp_parser_using_declaration. Tested x86_64-unkown-linux-gnu, OK to commit ? gcc/testsuite/ChangeLog 2011-12-11 Fabien Chêne fab...@gcc.gnu.org PR c++/14258 * g++.dg/template/using16.C: New. * g++.dg/template/using17.C: New. gcc/cp/ChangeLog 2011-12-11 Fabien Chêne fab...@gcc.gnu.org PR c++/14258 * cp-tree.h (USING_DECL_TYPENAME_P): New macro. * parser.c (cp_parser_nonclass_name): Handle using declarations that refer to a dependent type. (cp_parser_using_declaration): Set USING_DECL_TYPENAME_P to 1 if the using declaration refers to a dependent type. -- Fabien 14258.patch Description: Binary data
Re: [patch] PR51347 alias problem
On 12/10/11 17:13, Patrick Marlier wrote: On 12/10/2011 02:16 PM, Aldy Hernandez wrote: Using the parent node for aliases (as in your patch) makes sense, but I don't see tree_function_versioning() segfaulting as you claim. What I see is estimate_function_body_sizes() Humm you are seeing this I guess: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00427.html When applied, you should probably see the tree_function_versioning problem. Indeed. This is what I am seeing. I have applied and committed the patch and can no longer reproduce the problem. Can you verify on your end, and close the bug if appropriate? Thanks for all your help here.
Re: [PATCH 5/6] mips: Implement vec_perm_const.
Hans-Peter Nilsson h...@bitrange.com writes:
On Sun, 11 Dec 2011, Richard Sandiford wrote:
[Mingjie, please could you help with the Loongson question near the end?]
As H-P mentioned, this changes the __builtin_* interface for the PSHUFH
intrinsics. These intrinsics are supposed to be used via the inline
wrappers in loongson.h, so we can either keep the unused argument in
the pshufh_{u,s} or, as H-P suggests, remove the argument from both.
I don't know which is better. loongson.h needs to change either way,
so in the patch below, I went for the former. The latter would need
testsuite changes too. Mingjie, which do you think is best?
Please also consider incrementing __mips_loongson_vector_rev, or
if currently empty, set to 1. And mention PR48068 in the
changelog; fixed in part.
For avoidance of doubt, that only applies to the latter (as H-P
suggests) option. The patch as posted keeps the public interface
the same.
Richard
Re: [patch] PR51347 alias problem
On 12/11/2011 09:11 AM, Aldy Hernandez wrote: On 12/10/11 17:13, Patrick Marlier wrote: On 12/10/2011 02:16 PM, Aldy Hernandez wrote: Using the parent node for aliases (as in your patch) makes sense, but I don't see tree_function_versioning() segfaulting as you claim. What I see is estimate_function_body_sizes() Humm you are seeing this I guess: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00427.html When applied, you should probably see the tree_function_versioning problem. Indeed. This is what I am seeing. I have applied and committed the patch and can no longer reproduce the problem. Can you verify on your end, and close the bug if appropriate? Yes the testcase attached in the PR works for me but I can't change the status because I am not the reporter (nor admin). However, the testcase I have added g++.dg/tm/ctor-used.C fails. I can fill another PR but I found this problem thanks to the PR testcase. Thanks for all your help here. You are welcome. Patrick.
Re: [libstdc++] doc/xml/manual/abi.xml -- fix references to GCC as well as GNU/Linux
On 5 December 2011 00:04, Jonathan Wakely wrote: Yep, here's another patch with some more duplication removed. WIth this, the document only needs to be updated when a new symbol version is added or a library filename changes, not for every point release with identical library versions. I think I'm quite happy with this and will commit in a couple of days if noone objects. I committed that version and regenerated the HTML pages. * doc/xml/manual/abi.xml: Replace gcc-x.y.z with GCC x.y.z or x.y, remove excessive duplication of version information. * doc/html/*: Regenerate. Index: doc/xml/manual/abi.xml === --- doc/xml/manual/abi.xml (revision 181993) +++ doc/xml/manual/abi.xml (working copy) @@ -164,28 +164,14 @@ compatible. /para itemizedlist -listitemparagcc-3.0.0: libgcc_s.so.1/para/listitem -listitemparagcc-3.0.1: libgcc_s.so.1/para/listitem -listitemparagcc-3.0.2: libgcc_s.so.1/para/listitem -listitemparagcc-3.0.3: libgcc_s.so.1/para/listitem -listitemparagcc-3.0.4: libgcc_s.so.1/para/listitem -listitemparagcc-3.1.0: libgcc_s.so.1/para/listitem -listitemparagcc-3.1.1: libgcc_s.so.1/para/listitem -listitemparagcc-3.2.0: libgcc_s.so.1/para/listitem -listitemparagcc-3.2.1: libgcc_s.so.1/para/listitem -listitemparagcc-3.2.2: libgcc_s.so.1/para/listitem -listitemparagcc-3.2.3: libgcc_s.so.1/para/listitem -listitemparagcc-3.3.0: libgcc_s.so.1/para/listitem -listitemparagcc-3.3.1: libgcc_s.so.1/para/listitem -listitemparagcc-3.3.2: libgcc_s.so.1/para/listitem -listitemparagcc-3.3.3: libgcc_s.so.1/para/listitem -listitemparagcc-3.4.x, gcc-4.[0-5].x: libgcc_s.so.1/para/listitem +listitemparaGCC 3.x: libgcc_s.so.1/para/listitem +listitemparaGCC 4.x: libgcc_s.so.1/para/listitem /itemizedlist paraFor m68k-linux the versions differ as follows: /para itemizedlist -listitemparagcc-3.4.x, gcc-4.[0-5].x: libgcc_s.so.1 +listitemparaGCC 3.4, GCC 4.x: libgcc_s.so.1 when configuring code--with-sjlj-exceptions/code, or libgcc_s.so.2 /para /listitem /itemizedlist @@ -193,10 +179,10 @@ compatible. paraFor hppa-linux the versions differ as follows: /para itemizedlist -listitemparagcc-3.4.x, gcc-4.[0-1].x: either libgcc_s.so.1 +listitemparaGCC 3.4, GCC 4.[0-1]: either libgcc_s.so.1 when configuring code--with-sjlj-exceptions/code, or libgcc_s.so.2 /para /listitem -listitemparagcc-4.[2-5].x: either libgcc_s.so.3 when configuring +listitemparaGCC 4.[2-7]: either libgcc_s.so.3 when configuring code--with-sjlj-exceptions/code) or libgcc_s.so.4 /para /listitem /itemizedlist @@ -213,19 +199,22 @@ compatible. paraThis corresponds to the mapfile: gcc/libgcc-std.ver/para itemizedlist -listitemparagcc-3.0.0: GCC_3.0/para/listitem -listitemparagcc-3.3.0: GCC_3.3/para/listitem -listitemparagcc-3.3.1: GCC_3.3.1/para/listitem -listitemparagcc-3.3.2: GCC_3.3.2/para/listitem -listitemparagcc-3.3.4: GCC_3.3.4/para/listitem -listitemparagcc-3.4.0: GCC_3.4/para/listitem -listitemparagcc-3.4.2: GCC_3.4.2/para/listitem -listitemparagcc-3.4.4: GCC_3.4.4/para/listitem -listitemparagcc-4.0.0: GCC_4.0.0/para/listitem -listitemparagcc-4.1.0: GCC_4.1.0/para/listitem -listitemparagcc-4.2.0: GCC_4.2.0/para/listitem -listitemparagcc-4.3.0: GCC_4.3.0/para/listitem -listitemparagcc-4.4.0: GCC_4.4.0/para/listitem +listitemparaGCC 3.0.0: GCC_3.0/para/listitem +listitemparaGCC 3.3.0: GCC_3.3/para/listitem +listitemparaGCC 3.3.1: GCC_3.3.1/para/listitem +listitemparaGCC 3.3.2: GCC_3.3.2/para/listitem +listitemparaGCC 3.3.4: GCC_3.3.4/para/listitem +listitemparaGCC 3.4.0: GCC_3.4/para/listitem +listitemparaGCC 3.4.2: GCC_3.4.2/para/listitem +listitemparaGCC 3.4.4: GCC_3.4.4/para/listitem +listitemparaGCC 4.0.0: GCC_4.0.0/para/listitem +listitemparaGCC 4.1.0: GCC_4.1.0/para/listitem +listitemparaGCC 4.2.0: GCC_4.2.0/para/listitem +listitemparaGCC 4.3.0: GCC_4.3.0/para/listitem +listitemparaGCC 4.4.0: GCC_4.4.0/para/listitem +listitemparaGCC 4.5.0: GCC_4.5.0/para/listitem +listitemparaGCC 4.6.0: GCC_4.6.0/para/listitem +listitemparaGCC 4.7.0: GCC_4.7.0/para/listitem /itemizedlist /listitem @@ -241,54 +230,47 @@ compatible. constantDT_SONAME/constants are forward-compatibile: in the table below, releases incompatible with the previous one are explicitly noted. + If a particular release is not listed, its libstdc++.so binary + has the same filename and constantDT_SONAME/constant as the + preceding release. /para paraIt is versioned as follows: /para itemizedlist -listitemparagcc-3.0.0: libstdc++.so.3.0.0/para/listitem -listitemparagcc-3.0.1: libstdc++.so.3.0.1/para/listitem -
Re: [patch] add __is_final trait to fix libstdc++/51365
ping
On 3 December 2011 12:04, Jonathan Wakely wrote:
On 3 December 2011 12:00, Jonathan Wakely wrote:
This implements a new C++ trait, __is_final, to query the 'final'
specifier that 4.7 supports. The trait is needed for the library so we
can detect when it's not possible to derive from a type in order to
exploit the empty base-class optimisation. This affects all
containers, std::shared_ptr, std::future, std::tuple and anywhere else
that tries to use the EBO. It's not a C++11-only problem because we
support __final in c++98 mode. See PR libstdc++/51365 for examples of
programs using final classes that cause problems in libstdc++ and for
patches to the library that use this trait to solve the problems.
I originally thought about naming this __is_final_class, which would
allow a possible __is_final_function in future, but I think
__is_final(type) is pretty clear. There is a proposal to add
__is_final to Clang with the same spelling and semantics.
Tested x86_64-linux, ok for trunk?
c-family/ChangeLog:
* c-common.c (RID_IS_FINAL): Add.
* c-common.h (RID_IS_FINAL): Add.
cp/ChangeLog:
* cp-tree.h (CPTK_IS_FINAL): Add.
* parser.c (cp_parser_translation_unit): Handle RID_IS_FINAL.
(cp_parser_primary_expression, cp_parser_trait_expr): Likewise.
* semantics.c (trait_expr_value, finish_trait_expr): Handle
CPTK_IS_FINAL.
* cxx-pretty-print.c (pp_cxx_trait_expression): Likewise.
ChangeLog:
* doc/extend.texi (Type Traits): Add __is_final.
testsuite/ChangeLog:
* g++.dg/ext/is_final.C: New.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 181967)
+++ c-family/c-common.c (working copy)
@@ -462,6 +462,7 @@ const struct c_common_resword c_common_r
{ __is_convertible_to, RID_IS_CONVERTIBLE_TO, D_CXXONLY },
{ __is_empty, RID_IS_EMPTY, D_CXXONLY },
{ __is_enum, RID_IS_ENUM,D_CXXONLY },
+ { __is_final, RID_IS_FINAL, D_CXXONLY },
{ __is_literal_type, RID_IS_LITERAL_TYPE, D_CXXONLY },
{ __is_pod,RID_IS_POD, D_CXXONLY },
{ __is_polymorphic,RID_IS_POLYMORPHIC, D_CXXONLY },
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 181967)
+++ c-family/c-common.h (working copy)
@@ -134,7 +134,7 @@ enum rid
RID_CONSTCAST, RID_DYNCAST, RID_REINTCAST, RID_STATCAST,
/* C++ extensions */
- RID_BASES, RID_DIRECT_BASES,
+ RID_BASES, RID_DIRECT_BASES,
RID_HAS_NOTHROW_ASSIGN, RID_HAS_NOTHROW_CONSTRUCTOR,
RID_HAS_NOTHROW_COPY,RID_HAS_TRIVIAL_ASSIGN,
RID_HAS_TRIVIAL_CONSTRUCTOR, RID_HAS_TRIVIAL_COPY,
@@ -142,12 +142,12 @@ enum rid
RID_IS_ABSTRACT, RID_IS_BASE_OF,
RID_IS_CLASS,RID_IS_CONVERTIBLE_TO,
RID_IS_EMPTY,RID_IS_ENUM,
- RID_IS_LITERAL_TYPE, RID_IS_POD,
- RID_IS_POLYMORPHIC, RID_IS_STD_LAYOUT,
- RID_IS_TRIVIAL, RID_IS_UNION,
- RID_UNDERLYING_TYPE,
+ RID_IS_FINAL,RID_IS_LITERAL_TYPE,
+ RID_IS_POD, RID_IS_POLYMORPHIC,
+ RID_IS_STD_LAYOUT, RID_IS_TRIVIAL,
+ RID_IS_UNION,RID_UNDERLYING_TYPE,
- /* C++0x */
+ /* C++11 */
RID_CONSTEXPR, RID_DECLTYPE, RID_NOEXCEPT, RID_NULLPTR, RID_STATIC_ASSERT,
/* Objective-C (AT reserved words - they are only keywords when
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 181967)
+++ cp/cp-tree.h(working copy)
@@ -584,6 +584,7 @@ typedef enum cp_trait_kind
CPTK_IS_CONVERTIBLE_TO,
CPTK_IS_EMPTY,
CPTK_IS_ENUM,
+ CPTK_IS_FINAL,
CPTK_IS_LITERAL_TYPE,
CPTK_IS_POD,
CPTK_IS_POLYMORPHIC,
Index: cp/parser.c
===
--- cp/parser.c (revision 181967)
+++ cp/parser.c (working copy)
@@ -3854,6 +3854,7 @@ cp_parser_translation_unit (cp_parser* p
__is_convertible_to ( type-id , type-id )
__is_empty ( type-id )
__is_enum ( type-id )
+ __is_final ( type-id )
__is_literal_type ( type-id )
__is_pod ( type-id )
__is_polymorphic ( type-id )
@@ -4199,6 +4200,7 @@ cp_parser_primary_expression (cp_parser
case RID_IS_CONVERTIBLE_TO:
case RID_IS_EMPTY:
case RID_IS_ENUM:
+ case RID_IS_FINAL:
case RID_IS_LITERAL_TYPE:
case RID_IS_POD:
case RID_IS_POLYMORPHIC:
@@ -7868,6 +7870,9 @@ cp_parser_trait_expr (cp_parser* parser,
case RID_IS_ENUM:
kind = CPTK_IS_ENUM;
break;
+case RID_IS_FINAL:
+ kind = CPTK_IS_FINAL;
+ break;
case RID_IS_LITERAL_TYPE:
kind = CPTK_IS_LITERAL_TYPE;
break;
Index: cp/semantics.c
===
---
[patch] PR51388
Hello,
The configure scripts check for -Wno-narrowing, but GCC ignores rather
than rejects unknown -Wno-* warnings.
Fixed by checking for the positive warning, -Wnarrowing.
OK for trunk?
Ciao!
Steven
gcc/
PR bootstrap/51388
configure.ac: Check for Wnarrowing instead of Wno-narrowing.
configure: Regenerate.
libcpp/
PR bootstrap/51388
configure.ac: Check for Wnarrowing instead of Wno-narrowing.
configure: Regenerate.
Index: gcc/configure
===
--- gcc/configure (revision 182207)
+++ gcc/configure (working copy)
@@ -6400,7 +6400,7 @@ fi
loose_warn=
save_CFLAGS=$CFLAGS
-for option in -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual; do
+for option in -W -Wall -Wnarrowing -Wwrite-strings -Wcast-qual; do
as_acx_Woption=`$as_echo acx_cv_prog_cc_warning_$option | $as_tr_sh`
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether $CC supports
$option 5
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 182207)
+++ gcc/configure.ac(working copy)
@@ -333,7 +333,7 @@ GCC_STDINT_TYPES
# So, we only use -pedantic if we can disable those warnings.
ACX_PROG_CC_WARNING_OPTS(
- m4_quote(m4_do([-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual])),
[loose_warn])
+ m4_quote(m4_do([-W -Wall -Wnarrowing -Wwrite-strings -Wcast-qual])),
[loose_warn])
ACX_PROG_CC_WARNING_OPTS(
m4_quote(m4_do([-Wstrict-prototypes -Wmissing-prototypes])),
[c_loose_warn])
Index: libcpp/configure
===
--- libcpp/configure(revision 182207)
+++ libcpp/configure(working copy)
@@ -4688,7 +4688,7 @@ test -n $AUTOHEADER || AUTOHEADER=$MI
warn=
save_CFLAGS=$CFLAGS
-for option in -W -Wall -Wno-narrowing -Wwrite-strings \
+for option in -W -Wall -Wnarrowing -Wwrite-strings \
-Wmissing-format-attribute; do
as_acx_Woption=`$as_echo acx_cv_prog_cc_warning_$option | $as_tr_sh`
Index: libcpp/configure.ac
===
--- libcpp/configure.ac (revision 182207)
+++ libcpp/configure.ac (working copy)
@@ -33,7 +33,7 @@ AC_CHECK_PROGS([AUTOHEADER], [autoheader
# Figure out what compiler warnings we can enable.
# See config/warnings.m4 for details.
-ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wno-narrowing -Wwrite-strings \
+ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wnarrowing -Wwrite-strings \
-Wmissing-format-attribute], [warn])
ACX_PROG_CC_WARNING_OPTS([-Wstrict-prototypes -Wmissing-prototypes \
-Wold-style-definition -Wc++-compat], [c_warn])
Re: [Patch, fortran] - Arrays of classes for fortran
Dear Paul, dear all,
first, thanks again for the patch.
Paul Richard Thomas wrote:
Boostrapped and regtested on x86_64/FC9 - OK for trunk?
I have now re-read the patch and it is OK from my side. It wouldn't harm
is someone else with experience with CLASS or with the scalarizer could
also read the patch (before or after committal).
Nits:
* gfortran.dg/auto_dealloc_2.f90: Occurences of __builtin_free
now 2. * gfortran.dg/auto_dealloc_2.f90: Occurences of __builtin_free
* gfortran.dg/class_19.f03: Occurences of __builtin_free now 8.
Missing line break after 2..
+ for (ref = expr-ref; ref; ref = ref-next)
+ {
+ if (ref-type == REF_COMPONENT
+ ref-u.c.component-ts.type == BT_CLASS
+ ref-next ref-next-type == REF_COMPONENT
+ strcmp (ref-next-u.c.component-name, _data) == 0
+ ref-next-next
+ ref-next-next-type == REF_ARRAY
+ ref-next-next-u.ar.type != AR_ELEMENT)
+ {
+ ts =ref-u.c.component-ts;
+ class_ref = ref;
+ break;
+ }
+ }
Those lines look wrongly indented.
/* Generate code to initialize an allocate an array. Statements are added to
Untouched by your patch, but could you nevertheless fix the sentence by
changing an to and?
+ #if 0
+ if (expr-ts.type == BT_CLASS expr3)
+ {
+ tmp = build_int_cst (unsigned_char_type_node, 0);
+ /* With class objects, it is best to play safe and null the
+memory because we cannot know if dynamic types have allocatable
+components or not..
+OOP-TODO: Determine if this is necessary or not. */
and
+ else if (al-expr-ts.type == BT_CLASS code-expr3)
+ {
+ /* With class objects, it is best to play safe and null the
+memory because we cannot know if dynamic types have allocatable
+components or not. */
+ tmp = build_call_expr_loc (input_location,
+builtin_decl_explicit
(BUILT_IN_MEMSET),
+3, se.expr, integer_zero_node, memsz);
+ gfc_add_expr_to_block (se.pre, tmp);
+ }
Can the #if 0 ... #endif block be removed? Seemingly, you have not found
a case where it is not initialized. Additionally, I think the same
applies to the the second quote: If there is an expr3 (i.e. MOLD= or
SOURCE=) with a nonpolymorphic or with a polymorphic source-expr, either
the default initialization or the assignment should take care of the
allocatable components and similar issues.
If you really prefer to keep it (or them), can you fill a
missed-optimization PR?
After committal, can you write a quip for
http://gcc.gnu.org/wiki/GFortran#GCC4.7 ?
(Additionally, http://gcc.gnu.org/wiki/OOP and maybe
http://gcc.gnu.org/wiki/Fortran2003 could be updated.)
Tobias
Re: [PATCH 4/6] rs6000: Cleanup interleave/even_odd/vec_perm.
On 8 Dec 2011, at 21:06, Richard Henderson wrote:
;
+
+ high = (highp == TARGET_BIG_ENDIAN ? 0 : nelt);
+
This breaks bootstrap on ppc-darwin, which came as a bit f a surprise
to me...
... however, it would appear that TARGET_BIG_ENDIAN is not used
anywhere else...
(plenty of {BYTES,WORDS}_BIG_ENDIAN).
Note that there is no default for TARGET_BIG_ENDIAN in rs600.h - it is
only defined in config/rs6000/sysv4.h.
So is the patch below the correct 'obvious' fix, or was something else
intended.
cheers
Iain
gcc:
* config/rs6000/darwin.h (TARGET_BIG_ENDIAN): Define to 1.
Index: gcc/config/rs6000/darwin.h
===
--- gcc/config/rs6000/darwin.h (revision 182204)
+++ gcc/config/rs6000/darwin.h (working copy)
@@ -39,6 +39,8 @@
#define TARGET_OBJECT_FORMAT OBJECT_MACHO
+#define TARGET_BIG_ENDIAN 1
+
/* Size of the Obj-C jump buffer. */
#define OBJC_JBLEN ((TARGET_64BIT) ? (26*2 + 18*2 + 129 + 1) : (26 +
18*2 + 129 + 1))
Re: [PATCH 5/6] mips: Implement vec_perm_const.
On 12/11/2011 04:50 AM, Richard Sandiford wrote:
[Mingjie, please could you help with the Loongson question near the end?]
Actually, can you tell me how to test these abi combinations? I keep trying to
use mips-sim or mips64-sim and get linker errors complaining of abi
combinations.
Little-endian:
The semantics of the RTL pattern are:
{ 0L, 0U } = { X[I3], X[I4 + 2] }, where X = { 1L, 1U, 2L, 2U }
so: 0L = { 1L, 1U }[I3] (= bopbUL)
0U = { 2L, 2U }[I4] (= aopaUL)
aop = 2, aUL = I4 ? U : L
bop = 1, bUL = I3 ? U : L
[LL] !I4 !I3 [UL] I4 !I3
[LU] !I4 I3[UU] I4 I3
Big-endian:
The semantics of the RTL pattern are:
{ 0U, 0L } = { X[I3], X[I4 + 2] }, where X = { 1U, 1L, 2U, 2L }
so: 0U = { 1U, 1L }[I3] (= aopaUL)
0L = { 2U, 2L }[I4] (= bopbUL)
aop = 1, aUL = I3 ? L : U
bop = 2, bUL = I4 ? L : U
[UU] !I3 !I4 [UL] !I3 I4
[LU] I3 !I4[LL] I3 I4. */
which suggests that the PUL and PLU entries for big-endian should be
the other way around. Does that sound right, or have I misunderstood?
Yes, that sounds right.
...for little-endian, we need to pass the U and L components of the
mnemonic in the reverse order: the MIPS instruction specifies the upper
part first, whereas the rtl pattern specifies the lower part first.
And for little-endian, U refers to memory element 1 and L to memory
element 0. So I think this should be:
... Except that the actual output of the LE insn actually swaps the operands
too. So I think these expanders should not *also* swap the operands. I've
tidied these up a bit since then.
+static bool
+mips_expand_vpc_ps (struct expand_vec_perm_d *d)
I've eliminated this function since then.
+ /* Convert the selector into the packed 8-bit form for pshufh. */
+ for (i = mask = 0; i 4; i++)
+mask |= (d-perm[i] 3) (i * 2);
I think this is endian-dependent. For little-endian, the bottom two bits
of the mask determine element 0; for big-endian, the top two bits of the
mask do.
Recall that loongson can only run in little-endian. I added comments about
that in the md file, but it would do no harm to add another here.
(There's a machine in the farm, but bootstrapping on it is rather slow.)
Yeah, I started checking out the tree there yesterday and it never completed.
I think a lot of the endianness stuff in the patch is dependent on byte
endianness rather than word endianness. Since we only support two out
of the four combinations, it seems better not to worry which and simply
use TARGET_{BIG,LITTLE}_ENDIAN instead of {WORDS,BYTES}_{BIG,LITTLE}_ENDIAN.
Sure.
This is my current patch, which doesn't have the pul/plu insns swapped, as
suggested above. I did change the loongson.h interface as H-P suggested.
r~
commit b7790c7a9e53d66d1f348c3f2adb5b8a9bf2d93c
Author: Richard Henderson r...@redhat.com
Date: Wed Dec 7 14:17:02 2011 -0800
mips: Implement vec_perm_const.
diff --git a/gcc/config/mips/loongson.h b/gcc/config/mips/loongson.h
index 6bfd4d7..dfd6505 100644
--- a/gcc/config/mips/loongson.h
+++ b/gcc/config/mips/loongson.h
@@ -447,15 +447,15 @@ psadbh (uint8x8_t s, uint8x8_t t)
/* Shuffle halfwords. */
__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
-pshufh_u (uint16x4_t dest, uint16x4_t s, uint8_t order)
+pshufh_u (uint16x4_t s, uint8_t order)
{
- return __builtin_loongson_pshufh_u (dest, s, order);
+ return __builtin_loongson_pshufh_u (s, order);
}
__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
-pshufh_s (int16x4_t dest, int16x4_t s, uint8_t order)
+pshufh_s (int16x4_t s, uint8_t order)
{
- return __builtin_loongson_pshufh_s (dest, s, order);
+ return __builtin_loongson_pshufh_s (s, order);
}
/* Shift left logical. */
diff --git a/gcc/config/mips/loongson.md b/gcc/config/mips/loongson.md
index 225f4d1..7c7e29f 100644
--- a/gcc/config/mips/loongson.md
+++ b/gcc/config/mips/loongson.md
@@ -24,10 +24,7 @@
UNSPEC_LOONGSON_PCMPEQ
UNSPEC_LOONGSON_PCMPGT
UNSPEC_LOONGSON_PEXTR
- UNSPEC_LOONGSON_PINSR_0
- UNSPEC_LOONGSON_PINSR_1
- UNSPEC_LOONGSON_PINSR_2
- UNSPEC_LOONGSON_PINSR_3
+ UNSPEC_LOONGSON_PINSRH
UNSPEC_LOONGSON_PMADD
UNSPEC_LOONGSON_PMOVMSK
UNSPEC_LOONGSON_PMULHU
@@ -200,6 +197,51 @@
pandn\t%0,%1,%2
[(set_attr type fmul)])
+;; Logical AND.
+(define_insn *loongson_and
+ [(set (match_operand:VWHB 0 register_operand =f)
+ (and:VWHB (match_operand:VWHB 1 register_operand f)
+ (match_operand:VWHB 2 register_operand f)))]
+ TARGET_HARD_FLOAT TARGET_LOONGSON_VECTORS
+ and\t%0,%1,%2
+ [(set_attr type fmul)])
+
+;; Logical OR.
+(define_insn *loongson_or
+ [(set (match_operand:VWHB 0 register_operand =f)
+ (ior:VWHB (match_operand:VWHB 1 register_operand f)
+ (match_operand:VWHB 2
Re: [Patch, Fortran] PR50923 - [4.4-4.7] Print warning function does not return a value
Dear Tobias, Build and regtested on x86-64-linux. OK for the trunk? How far should this be backported - all the way down to 4.4? This is OK for trunk and... well, I don't know. 4.4 is likely a bit too far. I guess that the linux distros are already at 4.5? I will leave it to you. Cheers Paul
Re: [Patch, fortran] - Arrays of classes for fortran
Dear Tobias, On Sun, Dec 11, 2011 at 7:39 PM, Tobias Burnus bur...@net-b.de wrote: Dear Paul, dear all, first, thanks again for the patch. Thank you for the continuous reviewing over the last couple of months - also to Dominique, Salvatore and Damian; all of whom have kept the test cases coming in. Paul Richard Thomas wrote: Boostrapped and regtested on x86_64/FC9 - OK for trunk? Committed as revision 182210 with comments and corrections taken on board. Cheers Paul
Re: [committed] 4 backports from trunk to 4.6 branch
On Sun, Dec 11, 2011 at 02:48:52PM +0100, Mikael Pettersson wrote: This patch, r182112 on 4.6 branch, caused a test suite regression on arm-linux-gnueabi: +FAIL: gcc.c-torture/execute/20050713-1.c compilation, -O2 (internal compiler error) +UNRESOLVED: gcc.c-torture/execute/20050713-1.c execution, -O2 +FAIL: gcc.c-torture/execute/20050713-1.c compilation, -Os (internal compiler error) +UNRESOLVED: gcc.c-torture/execute/20050713-1.c execution, -Os because the compiler now ICEs: 20050713-1.c: In function 'bar3': 20050713-1.c:38:3: internal compiler error: in calculate_allocation, at vec.c:183 The same ICE also happens with today's trunk. Please file it into bugzilla (and the other bug too), I'll have a look. Jakub
warn about deprecated access declarations
Hi,
According to § 11.3/1 from c++98, access delarations are deprecated:
The access of a member of a base class can be changed in the derived
class by mentioning its qualified-id in the derived class declaration.
Such mention is called an access declaration. The effect of an access
declaration qualified-id; is defined to be equivalent to the
declaration usingqualified-id; [Footnote: Access declarations are
deprecated; member using-declarations (7.3.3) provide a better means
of doing the same things. In earlier versions of the C++ language,
access declarations were more limited; they were generalized and made
equivalent to using-declarations - end footnote]
Consequently, I propose to deprecate them with a warning, as clang already does.
So that you get a warning for the following code:
struct A { int i; };
struct B : A
{
A::i; // - warning here
};
warning: access declarations are deprecated; employ using declarations
instead [-Wdeprecated]
The warning is trivial to avoid, just add the keyword 'using' before
the access declaration.
Before adjusting the whole testsuite, I would like to know if there is
agreement to do it at stage 3.
The patch is really simple: (it does not include yet testsuite adjustements)
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 182209)
+++ gcc/cp/parser.c (working copy)
@@ -18900,7 +18900,11 @@ cp_parser_member_declaration (cp_parser*
parser-colon_corrects_to_scope_p = false;
if (cp_parser_using_declaration (parser, /*access_declaration=*/true))
-goto out;
+{
+ warning (OPT_Wdeprecated, access declarations are deprecated;
+ employ using declarations instead);
+ goto out;
+}
/* Parse the decl-specifier-seq. */
decl_spec_token_start = cp_lexer_peek_token (parser-lexer);
--
Fabien
Re: warn about deprecated access declarations
On 11 December 2011 22:22, Fabien Chêne wrote:
Consequently, I propose to deprecate them with a warning, as clang already
does.
So that you get a warning for the following code:
struct A { int i; };
struct B : A
{
A::i; // - warning here
};
warning: access declarations are deprecated; employ using declarations
instead [-Wdeprecated]
Whether or not it's suitable for stage 3, employ feels a bit clunky
in this context, how about access declarations are deprecated in
favour of using-declarations ?
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On Dec 9, 2011, at 11:45 AM, Aldy Hernandez wrote: How about the patch below? I'm fine with whatever you guys come up with...
Re: [PATCH 5/6] mips: Implement vec_perm_const.
On Sun, 11 Dec 2011, Richard Sandiford wrote: Hans-Peter Nilsson h...@bitrange.com writes: Please also consider incrementing __mips_loongson_vector_rev For avoidance of doubt, that only applies to the latter (as H-P suggests) option. The patch as posted keeps the public interface the same. Correct; I misread it, sorry. brgds, H-P
[google] Add support for delete operator that takes the size of the object as a parameter
In the tcmalloc memory
allocator(http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html),
deallocation involves a costly lookup to get the size of the deleted
object. The size is required to find the right free list to release
back the object. By passing the size of the object to the delete
call, this lookup can be avoided. This patch adds support for operator
delete(void*, size_t) guarded by a -fsized-delete flag. It also adds a
default implementation of delete(void *, size_t) that ignores the size
parameter.
Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
---
2011-12-11 Easwaran Raman era...@google.com
* common.opt (fsized-delete): New option.
cp/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman era...@google.com
* decl.c (cxx_init_decl_processing): Specify a function that
takes a void* and size_t for DELETE_EXPR.
* call.c (build_op_delete_call): If fsized-delete is used, use
the variant that takes size_t as the second parameter except
when deleteting a pointer of type void *.
testsuite/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman era...@google.com
* g++.dg/other/sized-delete-1.C: New test.
libstdc++-v3/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman era...@google.com
* libsupc++/del_op.cc (delete): Define a new variant
void operator delete(void*, std::size_t).
* libsupc++/new (delete): Declare
void operator delete(void*, std::size_t) throw();
* testsuite/util/testsuite_abi.cc (check_version): Add new
known version GLIBCXX_3.4.17.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Add
new symbol _ZdlPvm@@GLIBCXX_3.4.17.
* config/abi/pre/gnu.ver: Add new symbol _ZdlPvm at version
GLIBCXX_3.4.17.
Index: libstdc++-v3/libsupc++/del_op.cc
===
--- libstdc++-v3/libsupc++/del_op.cc (revision 182213)
+++ libstdc++-v3/libsupc++/del_op.cc (working copy)
@@ -46,3 +46,11 @@ operator delete(void* ptr) throw ()
if (ptr)
std::free(ptr);
}
+
+_GLIBCXX_WEAK_DEFINITION void
+operator delete(void* ptr,
+std::size_t bytes __attribute__((__unused__))) throw ()
+{
+ if (ptr)
+std::free(ptr);
+}
Index: libstdc++-v3/libsupc++/new
===
--- libstdc++-v3/libsupc++/new (revision 182213)
+++ libstdc++-v3/libsupc++/new (working copy)
@@ -93,6 +93,7 @@ namespace std
void* operator new(std::size_t) throw (std::bad_alloc);
void* operator new[](std::size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
+void operator delete(void*, std::size_t) throw();
void operator delete[](void*) throw();
void* operator new(std::size_t, const std::nothrow_t) throw();
void* operator new[](std::size_t, const std::nothrow_t) throw();
Index: libstdc++-v3/testsuite/util/testsuite_abi.cc
===
--- libstdc++-v3/testsuite/util/testsuite_abi.cc (revision 182213)
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc (working copy)
@@ -194,6 +194,7 @@ check_version(symbol test, bool added)
known_versions.push_back(GLIBCXX_3.4.14);
known_versions.push_back(GLIBCXX_3.4.15);
known_versions.push_back(GLIBCXX_3.4.16);
+ known_versions.push_back(GLIBCXX_3.4.17);
known_versions.push_back(GLIBCXX_LDBL_3.4);
known_versions.push_back(GLIBCXX_LDBL_3.4.7);
known_versions.push_back(GLIBCXX_LDBL_3.4.10);
@@ -560,4 +561,3 @@ demangle(const std::string mangled)
}
return name;
}
-
Index: libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
===
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt (revision 182213)
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt (working copy)
@@ -2422,6 +2422,7 @@ FUNC:_ZTv0_n24_NSt9strstreamD1Ev@@GLIBCXX_3.4
FUNC:_ZdaPv@@GLIBCXX_3.4
FUNC:_ZdaPvRKSt9nothrow_t@@GLIBCXX_3.4
FUNC:_ZdlPv@@GLIBCXX_3.4
+FUNC:_ZdlPvm@@GLIBCXX_3.4.17
FUNC:_ZdlPvRKSt9nothrow_t@@GLIBCXX_3.4
FUNC:_Znam@@GLIBCXX_3.4
FUNC:_ZnamRKSt9nothrow_t@@GLIBCXX_3.4
Index: libstdc++-v3/config/abi/pre/gnu.ver
===
--- libstdc++-v3/config/abi/pre/gnu.ver (revision 182213)
+++ libstdc++-v3/config/abi/pre/gnu.ver (working copy)
@@ -1279,6 +1279,13 @@ GLIBCXX_3.4.16 {
} GLIBCXX_3.4.15;
+GLIBCXX_3.4.17 {
+
+# operator delete(void*, , unsigned long)
+_ZdlPvm;
+
+} GLIBCXX_3.4.16;
+
# Symbols in the support library (libsupc++) have their own tag.
CXXABI_1.3 {
Index: gcc/testsuite/g++.dg/other/sized-delete-1.C
===
--- gcc/testsuite/g++.dg/other/sized-delete-1.C (revision 0)
+++ gcc/testsuite/g++.dg/other/sized-delete-1.C (revision
Re: [google] Backport r171347 and r181549 from trunk (strict volatile bitfield) (issue5434084)
Sorry about my oversight. I am on vacation now until Dec 19. I don't have good internet access now and I will backport this to upstream 4.6 after I come back if the 4.6 maintainers agree to take this. -Doug On Wed, Dec 7, 2011 at 9:02 PM, Richard Guenther richard.guent...@gmail.com wrote: On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote: This is a backport for two upstream patches into our 4.6 branch. I submitted the first patch by Julian a while ago for backport but Richard Earnshaw pointed out a problem with the first patch. The second patch from Joey fixes that problem. This was tested on x86 and ARM. Why hasn't this been proposed for upstream 4.6 instead? See PR51442. It's indeed annoying to see arm related backports only going to vendor branches, not the last officially maintained GCC release branch (4.6). I keep getting local requests to include random patches to our 4.6 build to make arm work at all. It seriously seems like having arm-linux-gnueabi as a primary target is a lie to our users. Arm maintainers - please consider maintaining at least the current release series and shift focus away from your vendor branches. Thanks, Richard. 2011-11-22 Doug Kwan dougk...@google.com Backport r171347 and r181549 from trunk. gcc/ 2011-03-23 Julian Brown jul...@codesourcery.com * expr.c (expand_expr_real_1): Only use BLKmode for volatile accesses which are not naturally aligned. 2011-11-20 Joey Ye joey...@arm.com * expr.c (expand_expr_real_1): Correctly handle strict volatile bitfield loads smaller than mode size. gcc/testsuite/ 2011-11-20 Joey Ye joey...@arm.com * gcc.dg/volatile-bitfields-1.c: New. Jakub
[PATCH, SMS] Add missing free operation in mark_loop_unsched
Hello, The patch below adds a missing free operation in mark_loop_unsched. Tested (bootstrap and regtest) ppc64-redhat-linux. OK for 3.7? Thanks, Revital Changelog: * modulo-sched.c (mark_loop_unsched): Free bbs. Index: modulo-sched.c === --- modulo-sched.c (revision 182198) +++ modulo-sched.c (working copy) @@ -1204,6 +1204,8 @@ mark_loop_unsched (struct loop *loop) for (i = 0; i loop-num_nodes; i++) bbs[i]-flags |= BB_DISABLE_SCHEDULE; + + free (bbs); } /* Return true if all the BBs of the loop are empty except the
Re: [PATCH, SMS] Add missing free operation in mark_loop_unsched
Hello, OK for 3.7? Sorry, I meant GCC 4.7.0... Thanks, Revital
[Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
Hi, This patch fixes dg-final scans in tests from vect.exp suite, which currently fail when avx2 is used. Ok for trunk? Changelog: 2011-12-12 Michael Zolotukhin michael.v.zolotuk...@intel.com * gcc.dg/vect/no-section-anchors-vect-31.c: Adjust diagnostic test to fix fail on AVX. * gcc.dg/vect/no-section-anchors-vect-66.c: Ditto. * gcc.dg/vect/no-section-anchors-vect-68.c: Ditto. * gcc.dg/vect/no-section-anchors-vect-69.c: Ditto. * gcc.dg/vect/no-vfa-vect-dv-2.c: Ditto. * gcc.dg/vect/pr45752.c: Ditto. * gcc.dg/vect/slp-perm-4.c: Ditto. * gcc.dg/vect/slp-perm-9.c: Ditto. * gcc.dg/vect/vect-33.c: Ditto. * gcc.dg/vect/vect-35.c: Ditto. * gcc.dg/vect/vect-6-big-array.c: Ditto. * gcc.dg/vect/vect-6.c: Ditto. * gcc.dg/vect/vect-91.c: Ditto. * gcc.dg/vect/vect-all-big-array.c: Ditto. * gcc.dg/vect/vect-all.c: Ditto. * gcc.dg/vect/vect-multitypes-1.c: Ditto. * gcc.dg/vect/vect-outer-4c.c: Ditto. * gcc.dg/vect/vect-outer-5.c: Ditto. * gcc.dg/vect/vect-over-widen-1.c: Ditto. * gcc.dg/vect/vect-over-widen-3.c: Ditto. * gcc.dg/vect/vect-over-widen-4.c: Ditto. * gcc.dg/vect/vect-peel-1.c: Ditto. * gcc.dg/vect/vect-peel-2.c: Ditto. * gcc.dg/vect/vect-peel-3.c: Ditto. * gcc.dg/vect/vect-reduc-pattern-1b.c: Ditto. * gcc.dg/vect/vect-reduc-pattern-1c.c: Ditto. * gcc.dg/vect/vect-reduc-pattern-2b.c: Ditto. * gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c: Ditto. * gcc.dg/vect/no-section-anchors-vect-36.c: Adjust array size to fix fail on AVX. * gcc.dg/vect/no-section-anchors-vect-64.c: Ditto. * lib/target-supports.exp (check_effective_target_vect_any_perm): New function. (check_effective_explicit_target_avx): Ditto. (check_effective_target_vect_aligned_arrays): Add handling of AVX. (check_effective_target_vect_multiple_sizes): Ditto. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation. vec-tests-avx2_fixes.patch Description: Binary data
Re: warn about deprecated access declarations
2011/12/11 Jonathan Wakely jwakely@gmail.com:
On 11 December 2011 22:22, Fabien Chêne wrote:
Consequently, I propose to deprecate them with a warning, as clang already
does.
So that you get a warning for the following code:
struct A { int i; };
struct B : A
{
A::i; // - warning here
};
warning: access declarations are deprecated; employ using declarations
instead [-Wdeprecated]
Whether or not it's suitable for stage 3, employ feels a bit clunky
in this context, how about access declarations are deprecated in
favour of using-declarations ?
Native spoker's suggestions are always very welcome, thanks !
(I was just trying to avoid using use ...)
--
Fabien
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
On Mon, Dec 12, 2011 at 11:06:37AM +0400, Michael Zolotukhin wrote:
diff --git a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
index 21b87a3..f75253e 100644
--- a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
+++ b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
@@ -88,5 +88,6 @@ int main (void)
/* { dg-final { scan-tree-dump-times vectorized 4 loops 1 vect } } */
/* { dg-final { scan-tree-dump-times Vectorizing an unaligned access 0
vect } } */
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 2 vect } } */
+/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 2 vect { target {! vect_multiple_sizes} } } } */
+/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 2 vect { xfail vect_multiple_sizes} } } */
/* { dg-final { cleanup-tree-dump vect } } */
The xfails are IMHO undesriable, then you just stop testing those tests on
very common developer platforms.
IMHO you should just use different dump-times count for the
vect_multipl_sizes (after checking it is the right count), if it doesn't
depend on -mprefer-avx128 vs. -mno-prefer-avx128. If it does,
then perhaps we want a predicate that details the vectorization factors
and their order.
Jakub
