[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
* 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
Am 08.12.2011 22:57, schrieb Jakub Jelinek:
Reading it again, isn't it overkill to keep the
vector? All you need is a bool and a way to restore its previous state.
Good catch. The vector was a leftover from the time when I was searching
up the call chain to check for any enclosing workshare.
Updated patch attached. I put a goto in there to simulate a double
"fall through", as you'll see in the patch. If anybody has strong
negative feelings about this, I will replace it with a switch within a
switch.
Regression-tested. OK for trunk (finally)?
Thomas
2011-12-11 Thomas Koenig
PR fortran/50690
* frontend-passes.c (in_omp_workshare): New variable.
(cfe_expr_0): Don't eliminiate common function if it would put
the variable immediately into a WORKSHARE construct.
(optimize_namespace): Set in_omp_workshare.
(gfc_code_walker): Keep track of OMP PARALLEL and OMP WORKSHARE
constructs.
2011-12-11 Thomas Koenig
PR fortran/50690
* gfortran.dg/gomp/workshare2.f90: New test.
* gfortran.dg/gomp/workshare3.f90: New test.
! { dg-do compile }
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
! Test that common function elimination is done within the OMP parallel
! blocks even if there is a workshare around it.
program foo
implicit none
integer, parameter :: n = 1000
real, parameter :: eps = 3e-7
integer :: i,j
real :: A(n), B(5), C(n)
real :: tmp
B(1) = 3.344
tmp = B(1)
do i=1,10
call random_number(a)
c = a
!$omp parallel workshare
!$omp parallel default(shared)
!$omp do
do j=1,n
A(j) = A(j)*cos(B(1))+A(j)*cos(B(1))
end do
!$omp end do
!$omp end parallel
!$omp end parallel workshare
end do
c = c*cos(b(1))+ c*cos(b(1))
do j=1,n
if (abs(a(j)-c(j)) > eps) then
print *,1,j,a(j), c(j)
call abort
end if
end do
end program foo
! { dg-final { scan-tree-dump-times "__builtin_cosf" 2 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
! { dg-do compile }
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
! PR 50690 - this used to ICE because workshare could not handle
! BLOCKs.
! To test for correct execution, run this program (but don't forget
! to unset the stack limit).
program foo
implicit none
integer, parameter :: n = 1000
real, parameter :: eps = 3e-7
integer :: i,j
real :: A(n), B(5), C(n)
real :: tmp
B(1) = 3.344
tmp = B(1)
do i=1,10
call random_number(a)
c = a
!$omp parallel default(shared)
!$omp workshare
A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
!$omp end workshare nowait
!$omp end parallel ! sync is implied here
end do
c = c*tmp + c*tmp
do j=1,n
if (abs(a(j)-c(j)) > eps) then
print *,1,j,a(j), c(j)
call abort
end if
end do
do i=1,10
call random_number(a)
c = a
!$omp parallel workshare default(shared)
A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
!$omp end parallel workshare
end do
c = c*tmp + c*tmp
do j=1,n
if (abs(a(j)-c(j)) > eps) then
print *,2,j,a(j), c(j)
call abort
end if
end do
end program foo
! { dg-final { scan-tree-dump-times "__var" 0 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 181809)
+++ frontend-passes.c (Arbeitskopie)
@@ -66,6 +66,10 @@ static gfc_namespace *current_ns;
static int forall_level;
+/* Keep track of whether we are within an OMP workshare. */
+
+static bool in_omp_workshare;
+
/* Entry point - run all passes for a namespace. So far, only an
optimization pass is run. */
@@ -367,6 +371,14 @@ cfe_expr_0 (gfc_expr **e, int *walk_subtrees,
int i,j;
gfc_expr *newvar;
+ /* Don't do this optimization within OMP workshare. */
+
+ if (in_omp_workshare)
+{
+ *walk_subtrees = 0;
+ return 0;
+}
+
expr_count = 0;
gfc_expr_walker (e, cfe_register_funcs, NULL);
@@ -505,6 +517,7 @@ optimize_namespace (gfc_namespace *ns)
current_ns = ns;
forall_level = 0;
+ in_omp_workshare = false;
gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
@@ -1150,11 +1163,13 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code
gfc_actual_arglist *a;
gfc_code *co;
gfc_association_list *alist;
+ bool saved_in_omp_workshare;
/* There might be statement insertions before the current code,
which must not affect the expression walker. */
co = *c;
+ saved_in_omp_workshare = in_omp_workshare;
switch (co->op)
{
@@ -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;
+
+
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
* gcc-interface/decl.c (gnat_to_gnu_entity) : 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
* 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
* 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
* 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 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 L be the lower part of operand and U be the upper part.
The P[UL][UL].PS instruction always specifies the upper part of the
result first, so the instruction is:
P.PS %0,,
where 0U == and 0L == .
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] (= )
0U = { 2L, 2U }[I4] (= )
= 2, = I4 ? U : L
= 1, = 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] (= )
0L = { 2U, 2L }[I4] (= )
= 1, = I3 ? L : U
= 2, = 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 (oper
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 > > Backport from mainline > 2011-12-08 Jakub Jelinek > > 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 > > 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 > > Backport from mainline > 2011-12-05 Jakub Jelinek > Eric Botcazou > > 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 > > 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 > Eric Botcazou > > 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 PR c++/14258 * g++.dg/template/using16.C: New. * g++.dg/template/using17.C: New. gcc/cp/ChangeLog 2011-12-11 Fabien Chêne 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 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. -gcc-3.0.0: libgcc_s.so.1 -gcc-3.0.1: libgcc_s.so.1 -gcc-3.0.2: libgcc_s.so.1 -gcc-3.0.3: libgcc_s.so.1 -gcc-3.0.4: libgcc_s.so.1 -gcc-3.1.0: libgcc_s.so.1 -gcc-3.1.1: libgcc_s.so.1 -gcc-3.2.0: libgcc_s.so.1 -gcc-3.2.1: libgcc_s.so.1 -gcc-3.2.2: libgcc_s.so.1 -gcc-3.2.3: libgcc_s.so.1 -gcc-3.3.0: libgcc_s.so.1 -gcc-3.3.1: libgcc_s.so.1 -gcc-3.3.2: libgcc_s.so.1 -gcc-3.3.3: libgcc_s.so.1 -gcc-3.4.x, gcc-4.[0-5].x: libgcc_s.so.1 +GCC 3.x: libgcc_s.so.1 +GCC 4.x: libgcc_s.so.1 For m68k-linux the versions differ as follows: -gcc-3.4.x, gcc-4.[0-5].x: libgcc_s.so.1 +GCC 3.4, GCC 4.x: libgcc_s.so.1 when configuring --with-sjlj-exceptions, or libgcc_s.so.2 @@ -193,10 +179,10 @@ compatible. For hppa-linux the versions differ as follows: -gcc-3.4.x, gcc-4.[0-1].x: either libgcc_s.so.1 +GCC 3.4, GCC 4.[0-1]: either libgcc_s.so.1 when configuring --with-sjlj-exceptions, or libgcc_s.so.2 -gcc-4.[2-5].x: either libgcc_s.so.3 when configuring +GCC 4.[2-7]: either libgcc_s.so.3 when configuring --with-sjlj-exceptions) or libgcc_s.so.4 @@ -213,19 +199,22 @@ compatible. This corresponds to the mapfile: gcc/libgcc-std.ver -gcc-3.0.0: GCC_3.0 -gcc-3.3.0: GCC_3.3 -gcc-3.3.1: GCC_3.3.1 -gcc-3.3.2: GCC_3.3.2 -gcc-3.3.4: GCC_3.3.4 -gcc-3.4.0: GCC_3.4 -gcc-3.4.2: GCC_3.4.2 -gcc-3.4.4: GCC_3.4.4 -gcc-4.0.0: GCC_4.0.0 -gcc-4.1.0: GCC_4.1.0 -gcc-4.2.0: GCC_4.2.0 -gcc-4.3.0: GCC_4.3.0 -gcc-4.4.0: GCC_4.4.0 +GCC 3.0.0: GCC_3.0 +GCC 3.3.0: GCC_3.3 +GCC 3.3.1: GCC_3.3.1 +GCC 3.3.2: GCC_3.3.2 +GCC 3.3.4: GCC_3.3.4 +GCC 3.4.0: GCC_3.4 +GCC 3.4.2: GCC_3.4.2 +GCC 3.4.4: GCC_3.4.4 +GCC 4.0.0: GCC_4.0.0 +GCC 4.1.0: GCC_4.1.0 +GCC 4.2.0: GCC_4.2.0 +GCC 4.3.0: GCC_4.3.0 +GCC 4.4.0: GCC_4.4.0 +GCC 4.5.0: GCC_4.5.0 +GCC 4.6.0: GCC_4.6.0 +GCC 4.7.0: GCC_4.7.0 @@ -241,54 +230,47 @@ compatible. DT_SONAMEs 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 DT_SONAME as the + preceding release. It is versioned as follows: -gcc-3.0.0: libstdc++.so.3.0.0 -gcc-3.0.1: libstdc++.so.3.0.1 -gcc-3.0.2: libstdc++.so.3.0.2 -gcc-3.0.3: libstdc++.so.3.0.2 (See Note 1) -gcc-3.0.4: libstdc++.so.3.0.4 -gcc-3.1.0: libstdc++.so.4.0.0 (Incompatible with previous) -gcc-3.1.1: libstdc++.so.4.0.1 -gcc-3.2.0: libstdc++.so.5.0.0 (Incompatible with previous) -gcc-3.2.1: libstdc++.so.5.0.1 -gcc-3.2.2: libstdc++.so.5.0.2 -gcc-3.2.3: libstdc++.so.5.0.3 (See Note 2) -gcc-3.3.0: libstdc++.so.5.0.4 -gcc-3.3.1: libstdc++.so.5.0.5 -gcc-3.3.2: libstdc++.so.5.0.5 -gcc-3.3.3: libstdc++.so.5.0.5 -gcc-3.4.0: libstdc++.so.6.0.0 (Incompatible with previous) -gcc-3.4.1: libstdc++.so.6.0.1 -gcc-3.4.2: libstdc++.so.6.0.2 -gcc-3.4.3: libstdc++.so.6.0.3 -gcc-3.4.4: libstdc++.so.6.0.3 -gcc-3.4.5: libstdc++.so.6.0.3 -gcc-3.4.6: libstdc++.so.6.0.3 -gcc-4.0.0: libstdc++.so.6.0.4 -gcc-4.0.1: libstdc++.so.6.0.5 -gcc-4.0.2: libstdc++.so.6.0.6 -gcc-4.0.3: libstdc++.so.6.0.7 -gcc-4.1.0: libstdc++.so.6.0.7 -gcc-4.1.1: libstdc++.so.6.0.8 -gcc-4.1.2: libstdc++.so.6.0.8 -gcc-4.2.0: libstdc++.so.6.0.9 -gcc-4.2.1: libstdc++.so.6.0.9 (See Note 3) -gcc-4.2.2: libstdc++.so.6.0.9 -gcc-4.2.3: libstdc++.so.6.0.9 -gcc-4.2.4: libstdc++.so.6.0.9 -gcc-4.3.0: libstdc++.so.6.0.10 -gcc-4.3.1: libstdc++.so.6.0.10 -gcc-4.3.2: libstdc++.so.6.0.10 -gcc-4.3.3: libstdc++.so.6.0.10 -gcc-4.3.4: libstdc++.so.6.0.10 -gcc-4.4.0: libstdc++.so.6.0.11 -gcc-4.4.1: libstdc++.so.6.0.12 -gcc-4.4.2: libstdc++.so.6.0.13 -gcc-4.5.0: libstdc++.so.6.0.14 +GCC 3.0.0: libstdc++.so.3.0.0 +
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:
[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 4/6] rs6000: Cleanup interleave/even_odd/vec_perm.
On 12/11/2011 10:44 AM, Iain Sandoe wrote: > Note that there is no default for TARGET_BIG_ENDIAN in rs600.h - it is only > defined in config/rs6000/sysv4.h. Gah. And of course that's all I tested w/ linux. Just change the TARGET_BIG_ENDIAN to BYTES_BIG_ENDIAN. r~
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] (= )
> 0U = { 2L, 2U }[I4] (= )
>
>= 2, = I4 ? U : L
>= 1, = 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] (= )
> 0L = { 2U, 2L }[I4] (= )
>
>= 1, = I3 ? L : U
>= 2, = 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
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_ope
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 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 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
* common.opt (fsized-delete): New option.
cp/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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
* g++.dg/other/sized-delete-1.C: New test.
libstdc++-v3/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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 0)
@@ -0,0 +1,14 @@
+// { dg-do link}
+// { dg-opt
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 wrote: > On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek 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 >>> >>> Backport r171347 and r181549 from trunk. >>> >>> gcc/ >>> 2011-03-23 Julian Brown >>> >>> * expr.c (expand_expr_real_1): Only use BLKmode for volatile >>> accesses which are not naturally aligned. >>> >>> 2011-11-20 Joey Ye >>> >>> * expr.c (expand_expr_real_1): Correctly handle strict >>> volatile >>> bitfield loads smaller than mode size. >>> >>> gcc/testsuite/ >>> 2011-11-20 Joey Ye >>> >>> * 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 * 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 :
> 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
