[Ada] Adjust internal flags for Do_Discrminant_Check
This is a preliminary internal change for setting Do_Discriminant_Check flags properly in the tree. No functional effect, so no test needed Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Robert Dewar * sinfo.ads, sinfo.adb: Change Do_Discriminant_Check to use new Flag1. Add this flag to type conversion nodes and assignment nodes. * treepr.adb: Deal properly with Flag 1,2,3. * treeprs.adt: Minor comment update. Index: sinfo.adb === --- sinfo.adb (revision 206804) +++ sinfo.adb (working copy) @@ -930,8 +930,10 @@ (N : Node_Id) return Boolean is begin pragma Assert (False -or else NT (N).Nkind = N_Selected_Component); - return Flag13 (N); +or else NT (N).Nkind = N_Assignment_Statement +or else NT (N).Nkind = N_Selected_Component +or else NT (N).Nkind = N_Type_Conversion); + return Flag1 (N); end Do_Discriminant_Check; function Do_Division_Check @@ -4078,8 +4080,10 @@ (N : Node_Id; Val : Boolean := True) is begin pragma Assert (False -or else NT (N).Nkind = N_Selected_Component); - Set_Flag13 (N, Val); +or else NT (N).Nkind = N_Assignment_Statement +or else NT (N).Nkind = N_Selected_Component +or else NT (N).Nkind = N_Type_Conversion); + Set_Flag1 (N, Val); end Set_Do_Discriminant_Check; procedure Set_Do_Division_Check Index: sinfo.ads === --- sinfo.ads (revision 206813) +++ sinfo.ads (working copy) @@ -638,9 +638,7 @@ --A flag set in the N_Subprogram_Body node for a subprogram body which --is acting as its own spec, except in the case of a library level --subprogram, in which case the flag is set on the parent compilation - --unit node instead (see further description in spec of Lib package). - --??? Above note about Lib is dubious since lib.ads does not mention - --Acts_As_Spec at all. + --unit node instead. -- Actual_Designated_Subtype (Node4-Sem) --Present in N_Free_Statement and N_Explicit_Dereference nodes. If gigi @@ -902,14 +900,16 @@ --that an accessibility check is required for the parameter. It is --not yet decided who takes care of this check (TBD ???). - -- Do_Discriminant_Check (Flag13-Sem) + -- Do_Discriminant_Check (Flag1-Sem) --This flag is set on N_Selected_Component nodes to indicate that a --discriminant check is required using the discriminant check routine --associated with the selector. The actual check is generated by the --expander when processing selected components. In the case of --Unchecked_Union, the flag is also set, but no discriminant check --routine is associated with the selector, and the expander does not - --generate a check. + --generate a check. This flag is also present in assignment statements + --(and set if the assignment requires a discriminant check), and in type + --conversion nodes (and set if the conversion requires a check). -- Do_Division_Check (Flag13-Sem) --This flag is set on a division operator (/ mod rem) to indicate @@ -1682,11 +1682,10 @@ --is undefined and should not be read). -- No_Ctrl_Actions (Flag7-Sem) - --Present in N_Assignment_Statement to indicate that no finalize nor - --adjust should take place on this assignment even though the rhs is + --Present in N_Assignment_Statement to indicate that no Finalize nor + --Adjust should take place on this assignment even though the RHS is --controlled. This is used in init procs and aggregate expansions where - --the generated assignments are more initialisations than real - --assignments. + --the generated assignments are initializations, not real assignments. -- No_Elaboration_Check (Flag14-Sem) --Present in N_Function_Call and N_Procedure_Call_Statement. Indicates @@ -3439,7 +3438,7 @@ -- Prefix (Node3) -- Selector_Name (Node2) -- Associated_Node (Node4-Sem) - -- Do_Discriminant_Check (Flag13-Sem) + -- Do_Discriminant_Check (Flag1-Sem) -- Is_In_Discriminant_Check (Flag11-Sem) -- Is_Prefixed_Call (Flag17-Sem) -- Atomic_Sync_Required (Flag14-Sem) @@ -4197,12 +4196,13 @@ -- Sloc points to first token of subtype mark -- Subtype_Mark (Node4) -- Expression (Node3) + -- Do_Discriminant_Check (Flag1-Sem) + -- Do_Length_Check (Flag4-Sem) + -- Float_Truncate (Flag11-Sem) -- Do_Tag_Check (Flag13-Sem) - -- Do_Length_Check (Flag4-Sem) + -- Conversion_OK (Flag14-Sem) -- Do_Overflow_Check (Flag17-Sem) - -- Float_Truncate (Flag11-Sem) -- Rounded_Result (Flag18-Sem) - -- Conversion_OK (Flag14-Sem)
[Ada] Spurious visibility error for operator in pre-condition
If a user-defined operator renames a predefined one, a use of that operator is rewritten with the predefined one, because the back-end requires it. This transformation must not be performed when analyzing the expression in a pre- or postcondition aspect or pragma, because the expression will be reanalyzed at a later point, and the rewriting may affect vsibility of the operator, typically within an instance, where the operator may be a defaulted formal subprogram. The following must compile quietly gcc -c libm.adb gcc -c -gnata libm.adb --- package Libm is pragma Pure; procedure Req_Body; end Libm; --- with Libm.Aux; use Libm.Aux; package body Libm is function Exact (X : Float) return Float is (X); package Float_Approximations is new Generic_Float_Approximations (Float); use Float_Approximations; procedure Req_Body is null; end Libm; -- package body Libm.Aux is use Ada.Numerics; generic type T is private; with function Multiply_Add (X, Y, Z : T) return T is <>; package Generic_Polynomials is type Polynomial is array (Positive range <>) of T; function Compute_Horner (P : Polynomial; X : T) return T with Inline; end Generic_Polynomials; package body Generic_Polynomials is function Compute_Horner (P : Polynomial; X : T) return T is Result : T := P (P'Last); begin for P_j of reverse P (P'First .. P'Last - 1) loop Result := Multiply_Add (Result, X, P_j); end loop; return Result; end Compute_Horner; end Generic_Polynomials; function Multiply_Add (X, Y, Z : Float) return Float is (X * Y + Z); package Float_Polynomials is new Generic_Polynomials (Float); use Float_Polynomials; package body Generic_Float_Approximations is function Multiply_Add (X, Y, Z : T) return T is (X * Y + Z); package Float_Polynomials is new Generic_Polynomials (T); use Float_Polynomials; function Approx_Sin (X : T) return T is -- Hart's constants: #SIN 3040# (p. 199) P1 : constant T := Exact (-0.1_66567); P2 : constant T := Exact (0.83320_15015E-2); P3 : constant T := Exact (-0.19501_81031E-3); Result : T; G : constant T := X * X; begin Result := Compute_Horner ((P1, P2, P3), G); return Multiply_Add (X, Result * G, X); end Approx_Sin; end Generic_Float_Approximations; end Libm.Aux; --- with Ada.Numerics; package Libm.Aux is pragma Pure; generic type T is private; with function "+" (X, Y : T) return T is <>; with function "*" (X, Y : T) return T is <>; with function "+" (X : T) return T is <>; with function "<=" (X, Y : T) return Boolean is <>; with function "abs" (X : T) return T is <>; with function Exact (X : Float) return T is <>; package Generic_Float_Approximations is -- The approximations in this package will work well for single -- precision floating point types. function Approx_Sin (X : T) return T with Pre => (abs X) <= Exact (Ada.Numerics.Pi / 2.0), Post => (abs Approx_Sin'Result) <= Exact (1.0); end Generic_Float_Approximations; end Libm.Aux; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Ed Schonberg * sem_res.adb (Rewrite_Renamed_Operator): Do not replace entity with the operator it renames if we are within an expression of a pre/postcondition, because the expression will be reanalyzed at a later point, and the analysis of the renaming may affect the visibility of the operator when in an instance. Index: sem_res.adb === --- sem_res.adb (revision 206844) +++ sem_res.adb (working copy) @@ -10301,6 +10301,14 @@ Op_Node : Node_Id; begin + -- Do not perform this transformation within a pre/postcondition, + -- because the expression will be re-analyzed, and the transformation + -- might affect the visibility of the operator, e.g. in an instance. + + if In_Assertion_Expr > 0 then + return; + end if; + -- Rewrite the operator node using the real operator, not its renaming. -- Exclude user-defined intrinsic operations of the same name, which are -- treated separately and rewritten as calls.
[Ada] Spurious visibility error with nlined subprogram in with-clauses
A compilation unit that is a subprogram is rewritten as a package (the wrapper package) containing the body of the actual subprogram instance. The wrapping happens when the unit is compiled upon its appearance in the context of some unit. If it appears in several such contexts, and the subprogram is marked Inline, some units only see the wrapper package. Each unit in a context is made into a visible library unit, and when the unit is the wrapper package, it is the related instance (the subprogram) that must be made visible. Prior to this patch, only the converse was done, namely the visible library unit flag was reset on exit from a given context, but not set when isntalling context. Executing gnatmake -q -gnato -gnatn -gnatwa -gnatQ main main must yield: OK --- with GNAT.IO; use GNAT.IO; with Case_Handling_J; procedure main is begin Put_Line (Case_Handling_J.Get); end main; --- with Ada.Containers.Indefinite_Hashed_Maps; with Ada.Strings.Wide_Wide_Hash; package Case_Handling is S : Wide_Wide_String := ""; private type W_Node is record Read_Only : Boolean; end record; package Casing_Exception_Table is new Ada.Containers.Indefinite_Hashed_Maps (Key_Type=> Wide_Wide_String, Element_Type=> W_Node, Hash=> Ada.Strings.Wide_Wide_Hash, Equivalent_Keys => "="); use Casing_Exception_Table; end Case_Handling; --- with Ada.Containers; package Case_Handling_J is function JNI_For_Body_Elaboration return Ada.Containers.Hash_Type; function Get return String; end Case_Handling_J; --- with Ada.Strings.Wide_Wide_Hash; with Case_Handling; package body Case_Handling_J is function JNI_For_Body_Elaboration return Ada.Containers.Hash_Type is begin return Ada.Strings.Wide_Wide_Hash (Case_Handling.S); end; function Get return String is begin return "OK"; end; end Case_Handling_J; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Ed Schonberg * sem_ch10.adb (Install_Withed_Unit): If the unit is a subprogram instance that is inlined, it may have been rewritten as a wrapper package. In that case the unit that must be made visible is the related instance of the package. Index: sem_ch10.adb === --- sem_ch10.adb(revision 206813) +++ sem_ch10.adb(working copy) @@ -5156,6 +5156,14 @@ Set_Is_Visible_Lib_Unit (Uname); +-- If the unit is a wrapper package for a compilation unit that is +-- a subprogrm instance, indicate that the instance itself is a +-- visible unit. This is necessary if the instance is inlined. + +if Is_Wrapper_Package (Uname) then + Set_Is_Visible_Lib_Unit (Related_Instance (Uname)); +end if; + -- If the child unit appears in the context of its parent, it is -- immediately visible. @@ -6447,6 +6455,7 @@ -- If the unit is a wrapper package, the subprogram instance is -- what must be removed from visibility. + -- Should we use Related_Instance instead??? if Is_Wrapper_Package (Unit_Name) then Set_Is_Immediately_Visible (Current_Entity (Unit_Name), False);
[Ada] Update spec for Compile_Time_Known_Value
This is an internal change to documentation, and the interface to one function in the compiler. No functional effect, so no test needed. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Robert Dewar * sem_eval.adb (Compile_Time_Known_Value): Add Ignore_CRT parameter. * sem_eval.ads (Compile_Time_Known_Value): Add Ignore_CRT parameter, completely rewrite spec. Index: sem_eval.adb === --- sem_eval.adb(revision 206841) +++ sem_eval.adb(working copy) @@ -1287,7 +1287,10 @@ -- Compile_Time_Known_Value -- -- - function Compile_Time_Known_Value (Op : Node_Id) return Boolean is + function Compile_Time_Known_Value + (Op : Node_Id; + Ignore_CRT : Boolean := False) return Boolean + is K : constant Node_Kind := Nkind (Op); CV_Ent : CV_Entry renames CV_Cache (Nat (Op) mod CV_Cache_Size); @@ -1311,9 +1314,9 @@ -- time. This avoids anomalies where whether something is allowed with a -- given configurable run-time library depends on how good the compiler -- is at optimizing and knowing that things are constant when they are - -- nonstatic. + -- nonstatic. This check is suppressed if Ignore_CRT is True - if Configurable_Run_Time_Mode + if (Configurable_Run_Time_Mode and not Ignore_CRT) and then K /= N_Null and then not Is_Static_Expression (Op) then @@ -1326,7 +1329,6 @@ and then Etype (Entity (Op)) = Standard_Boolean then null; - else return False; end if; Index: sem_eval.ads === --- sem_eval.ads(revision 206804) +++ sem_eval.ads(working copy) @@ -85,14 +85,14 @@ -- does not raise constraint error. In fact for certain legality checks not -- only do we need to ascertain that the expression is static, but we must -- also ensure that it does not raise constraint error. - -- + -- Neither of Is_Static_Expression and Is_OK_Static_Expression should be -- used for compile time evaluation purposes. In fact certain expression - -- whose value is known at compile time are not static in the RM 4.9 sense. - -- A typical example is: - -- + -- whose value may be known at compile time are not static in the RM 4.9 + -- sense. A typical example is: + -- C : constant Integer := Record_Type'Size; - -- + -- The expression 'C' is not static in the technical RM sense, but for many -- simple record types, the size is in fact known at compile time. When we -- are trying to perform compile time constant folding (for instance for @@ -100,8 +100,8 @@ -- are not the right functions to test if folding is possible. Instead, we -- use Compile_Time_Known_Value. All static expressions that do not raise -- constraint error (i.e. those for which Is_OK_Static_Expression is true) - -- are known at compile time, but as shown by the above example, there are - -- cases of non-static expressions which are known at compile time. + -- are known at compile time, but as shown by the above example, there may + -- be cases of non-static expressions which are known at compile time. - -- Subprograms -- @@ -224,15 +224,60 @@ -- Determine whether two types T1, T2, which have the same base type, -- are statically matching subtypes (RM 4.9.1(1-2)). - function Compile_Time_Known_Value (Op : Node_Id) return Boolean; + function Compile_Time_Known_Value + (Op : Node_Id; + Ignore_CRT : Boolean := False) return Boolean; -- Returns true if Op is an expression not raising Constraint_Error whose - -- value is known at compile time. This is true if Op is a static + -- value is known at compile time and for which a call to Expr_Value can + -- be used to determine this value. This is always true if Op is a static -- expression, but can also be true for expressions which are technically - -- non-static but which are in fact known at compile time, such as the - -- static lower bound of a non-static range or the value of a constant - -- object whose initial value is static. Note that this routine is defended - -- against unanalyzed expressions. Such expressions will not cause a - -- blowup, they may cause pessimistic (i.e. False) results to be returned. + -- non-static but which are in fact known at compile time. Some possible + -- examples of such expressions might be the static lower bound of a + -- non-static range or the value of a constant object whose initial + -- value is itself compile time known in the sense of this routine. Note + -- that this routine is defended against unanalyzed expressions. Such + -- expressions will not cause a blowup, they may caus
Re: Commit: MSP430: Add -mcpu= option
Hi Gerald, "command-line option", I think, and I suggest to use ... around the actual options. OK - I have made those changes and committed the result. Cheers Nick
Re: RFC Asan instrumentation control
> Thanks, commited in 206458 without c-c++-common/asan/no-asan-stack.c > testfile. ... This caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897. TIA Dominique
Re: [patch] fix libstdc++/56267 - local iterator requirements
On 20 January 2014 21:11, François Dumont wrote: > On 01/20/2014 04:53 PM, Jonathan Wakely wrote: > > With this new design couldn't we change the conditions that are used to > decide when to cache the hash code. I haven't study it in detail but it > looks like the default constructible constraint could be removed, no ? Ah yes, I forgot about that part, I'll update the __cache_default definition. Thanks.
Re: [Patch] Fix regex `nosubs` correctly
On 20/01/14 17:43 -0500, Tim Shen wrote: The semantic of `nosubs` should simply be that `let all parentheses not be a subexpression and do not capture it`. It's not clear to me whether the standard says that nosubs implies mark_count() == 0 or that the mark count remains the same, but no sub-expression matches are stored in the results. What does Boost.Regex do?
RE: [PING][PATCH]Improving mklog [was: Re: RFC Asan instrumentation control]
> Apologies for the delay. The patch is OK. Thanks. Committed revision 206875. Thank you, Tatiana Udalova
[PATCH] Fix for PR59600
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions with
mismatching no_sanitize_address attributes should not be considered for
inlining, otherwise the meaning of no_sanitize_address will not be
preserved.
I didn't get feedback in Bugzilla so I'm sending the patch here.
Bootstrapped/regtested on x64.
-Y
gcc/ChangeLog:
2014-01-21 ygribov
* cif-code.def (OPTION_MISMATCH): New CIF code.
* ipa-inline.c (report_inline_failed_reason): Handle mismatched
sanitization attributes.
(sanitize_attrs_match_for_inline_p): New function.
(can_inline_edge_p): Likewise.
gcc/testsuite/ChangeLog:
2014-01-21 ygribov
* gcc.dg/asan/nosanitize-and-inline.c: : New test.
diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index f1df5a0..1418f8e 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -109,3 +109,6 @@ DEFCIFCODE(OPTIMIZATION_MISMATCH, N_("optimization level attribute mismatch"))
/* We can't inline because the callee refers to comdat-local symbols. */
DEFCIFCODE(USES_COMDAT_LOCAL, N_("callee refers to comdat-local symbols"))
+
+/* We can't inline because of mismatched options. */
+DEFCIFCODE(OPTION_MISMATCH, N_("option mismatch"))
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 12ee84c..9118561 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -234,7 +234,25 @@ report_inline_failed_reason (struct cgraph_edge *e)
}
}
-/* Decide if we can inline the edge and possibly update
+ /* Decide whether sanitizer-related attributes allow inlining. */
+
+static bool
+sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee)
+{
+ /* Don't care if sanitizer is disabled */
+ if (!(flag_sanitize & SANITIZE_ADDRESS))
+return true;
+
+ if (!caller || !callee)
+return true;
+
+ return lookup_attribute ("no_sanitize_address",
+ DECL_ATTRIBUTES (caller)) ==
+lookup_attribute ("no_sanitize_address",
+ DECL_ATTRIBUTES (callee));
+}
+
+ /* Decide if we can inline the edge and possibly update
inline_failed reason.
We check whether inlining is possible at all and whether
caller growth limits allow doing so.
@@ -327,6 +345,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
e->inline_failed = CIF_TARGET_OPTION_MISMATCH;
inlinable = false;
}
+ /* Don't inline a function with mismatched sanitization attributes. */
+ else if (!sanitize_attrs_match_for_inline_p (e->caller->decl, callee->decl))
+{
+ e->inline_failed = CIF_OPTION_MISMATCH;
+ inlinable = false;
+}
/* Check if caller growth allows the inlining. */
else if (!DECL_DISREGARD_INLINE_LIMITS (callee->decl)
&& !disregard_limits
diff --git a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
index e69de29..5853801 100644
--- a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
+++ b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
@@ -0,0 +1,57 @@
+/* { dg-do run } */
+
+/* This is a simplified version of what Emacs does internally,
+ when marking its stack. */
+
+static unsigned long sum;
+static void *stack_base;
+
+/* A simple substitute for what Emacs actually does. */
+static void
+mark_maybe_pointer (void *p)
+{
+ sum ^= (unsigned long) p;
+}
+
+static inline void __attribute__ ((no_sanitize_address))
+mark_memory (void **start, void **end)
+{
+ void **pp;
+
+ if (end < start)
+{
+ void **tem = start;
+ start = end;
+ end = tem;
+}
+
+ for (pp = start; pp < end; pp++)
+{
+ /* This is the dereference that we don't want sanitized. */
+ void *p = *pp;
+
+ mark_maybe_pointer (p);
+}
+}
+
+static void
+mark_stack (void)
+{
+ void *end;
+ mark_memory (stack_base, &end);
+}
+
+void
+garbage_collect (void)
+{
+ mark_stack ();
+}
+
+int
+main (void)
+{
+ void *dummy;
+ stack_base = &dummy;
+ garbage_collect ();
+ return 0;
+}
[AArch64] fix big.LITTLE spec rewriting
Hi,
As Charles Baylis pointed out here:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00921.html
The way that we rewrite command lines for big.LITTLE systems
causes bugs where more than one source file is to be used.
The problem fundamentally is that -mcpu never makes it to
the second cc1 invocation.
This patch changes the spec command we use and updates
aarch64-common.c to handle that fact. I confess that the specs
stuff all looks like magic to me, but this approach seems to
make sense. In English, I think I am saying:
"If you find an mcpu= followed by some name, rewrite that to be
-mcpu followed by the results of passing all other -mcpu values
we find through aarch64_rewrite_mcpu"
I've regression tested this patch on aarch64-none-elf with no
issues and checked combinations of zero or more -mcpu values with
one or more source files, and things seem to work as expected.
OK?
Thanks,
James
---
2014-01-21 James Greenhalgh
* common/config/aarch64/aarch64-common.c
(aarch64_rewrite_mcpu): Handle multiple names.
* config/aarch64/aarch64.h
(BIG_LITTLE_SPEC): Do not discard mcpu switches.
diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index 6107007..e44b40a 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -110,13 +110,15 @@ aarch64_rewrite_selected_cpu (const char *name)
/* Called by the driver to rewrite a name passed to the -mcpu
argument in preparation to be passed to the assembler. The
- name will be in ARGV[0], ARGC should always be 1. */
+ names passed from the commend line will be in ARGV, we want
+ to use the right-most argument, which should be in
+ ARGV[ARGC - 1]. ARGC should always be greater than 0. */
const char *
aarch64_rewrite_mcpu (int argc, const char **argv)
{
- gcc_assert (argc == 1);
- return aarch64_rewrite_selected_cpu (argv[0]);
+ gcc_assert (argc);
+ return aarch64_rewrite_selected_cpu (argv[argc - 1]);
}
#undef AARCH64_CPU_NAME_LENGTH
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index a08dee0..13c424c 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -857,7 +857,7 @@ extern enum aarch64_code_model aarch64_cmodel;
(BYTES_BIG_ENDIAN ? GET_MODE_NUNITS (mode) - 1 - n : n)
#define BIG_LITTLE_SPEC \
- " %{mcpu=*:%
[ARM] fix big.LITTLE spec rewriting
Hi,
As with the AArch64 case,
( http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01317.html )
the way that we rewrite command lines for big.LITTLE systems
causes bugs where more than one source file is to be used.
The solution here is identical to that proposed for AArch64,
we update the spec command and compensate for that with an
change to arm_rewrite_mcpu to handle multiple names.
The patch has been bootstrapped on a chromebook, and I've
checked combinations of zero or more -mcpu values with
one or more source files, and things seem to work as expected.
OK?
Thanks,
James
---
2014-01-21 James Greenhalgh
* common/config/arm/arm-common.c
(arm_rewrite_mcpu): Handle multiple names.
* config/arm/arm.h
(BIG_LITTLE_SPEC): Do not discard mcpu switches.
diff --git a/gcc/common/config/arm/arm-common.c b/gcc/common/config/arm/arm-common.c
index 065de7d..8ef8d83 100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -86,13 +86,15 @@ arm_rewrite_selected_cpu (const char *name)
/* Called by the driver to rewrite a name passed to the -mcpu
argument in preparation to be passed to the assembler. The
- name will be in ARGV[0], ARGC should always be 1. */
+ names passed from the commend line will be in ARGV, we want
+ to use the right-most argument, which should be in
+ ARGV[ARGC - 1]. ARGC should always be greater than 0. */
const char *
arm_rewrite_mcpu (int argc, const char **argv)
{
- gcc_assert (argc == 1);
- return arm_rewrite_selected_cpu (argv[0]);
+ gcc_assert (argc);
+ return arm_rewrite_selected_cpu (argv[argc - 1]);
}
#undef ARM_CPU_NAME_LENGTH
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index b815488..bed056e 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2356,7 +2356,7 @@ extern int making_const_table;
#define MAX_LDM_STM_OPS 4
#define BIG_LITTLE_SPEC \
- " %{mcpu=*:%
[Ada] Allow to extend a project imported only by extended projects
A project that is imported by an extended project was not allowed to be extended. This patch fixes this. Invoking gnatmake -P test_util.gpr should not result in an error such as cannot extend an already imported project file or cannot import an already extended project file with "test_b.gpr"; with "test_a.gpr"; project Test_Unit is end Test_Unit; project A is end A; project Test_A extends "a.gpr" is end Test_A; with "a.gpr"; project B is end B; project Test_B extends "b.gpr" is end Test_B; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Vincent Celier * prj-part.adb (Parse_Single_Project): Accept to extend a project if it has only be imported by an project being extended. When a project that has only been imported by a project being extended is imported by another project that is not being extended, reset the previous indication, so that it will be an error if this project is extended later. * prj-tree.adb (Create_Project): Include component From_Extended in table Projects_HT * prj-tree.ads (Project_Name_And_Node): New Boolean component From_Extended Index: prj-part.adb === --- prj-part.adb(revision 206804) +++ prj-part.adb(working copy) @@ -1325,11 +1325,20 @@ "cannot extend the same project file several times", Token_Ptr); end if; - else + elsif not A_Project_Name_And_Node.From_Extended then Error_Msg (Env.Flags, "cannot extend an already imported project file", Token_Ptr); + + else + -- Register this project as being extended + + A_Project_Name_And_Node.Extended := True; + Tree_Private_Part.Projects_Htable.Set +(In_Tree.Projects_HT, + A_Project_Name_And_Node.Name, + A_Project_Name_And_Node); end if; elsif A_Project_Name_And_Node.Extended then @@ -1372,6 +1381,16 @@ "cannot import an already extended project file", Token_Ptr); end if; + +elsif A_Project_Name_And_Node.From_Extended then + -- This project is now imported from a non extending project. + -- Indicate this in has table Projects.HT. + + A_Project_Name_And_Node.From_Extended := False; + Tree_Private_Part.Projects_Htable.Set + (In_Tree.Projects_HT, + A_Project_Name_And_Node.Name, + A_Project_Name_And_Node); end if; Project := A_Project_Name_And_Node.Node; @@ -1933,6 +1952,7 @@ Node => Project, Canonical_Path => Canonical_Path_Name, Extended => Extended, + From_Extended => From_Extended /= None, Proj_Qualifier => Project_Qualifier_Of (Project, In_Tree))); end if; Index: prj-tree.adb === --- prj-tree.adb(revision 206804) +++ prj-tree.adb(working copy) @@ -1321,8 +1321,7 @@ begin pragma Assert (Present (Node) - and then -In_Tree.Project_Nodes.Table (Node).Kind = N_Term); + and then In_Tree.Project_Nodes.Table (Node).Kind = N_Term); return In_Tree.Project_Nodes.Table (Node).Field2; end Next_Term; @@ -1332,18 +1331,17 @@ function Next_Variable (Node: Project_Node_Id; - In_Tree : Project_Node_Tree_Ref) - return Project_Node_Id + In_Tree : Project_Node_Tree_Ref) return Project_Node_Id is begin pragma Assert (Present (Node) and then - (In_Tree.Project_Nodes.Table (Node).Kind = - N_Typed_Variable_Declaration +(In_Tree.Project_Nodes.Table (Node).Kind = + N_Typed_Variable_Declaration or else -In_Tree.Project_Nodes.Table (Node).Kind = - N_Variable_Declaration)); + In_Tree.Project_Nodes.Table (Node).Kind = + N_Variable_Declaration)); return In_Tree.Project_Nodes.Table (Node).Field3; end Next_Variable; @@ -2925,6 +2923,7 @@ Canonical_Path => No_Path, Node => Project, Extended => False, + From_Extended => False, Proj_Qualifier => Qualifier)); end if; Index: prj-tree.ads === --- prj-tree.ads(revision 206804) +++ prj-tree.ads(working copy) @@
[Ada] Work on pragma SPARK_Mode
This patch redoes the data structures for pragma SPARK_Mode so that the tree captures full information on the SPARK_Mode setting in all cases, so that it can easily be accessed by gnat2why. It also fully implements the error checking on "monotonicity" of SPARK_Mode settings, and also properly checks for duplicate pragmas in a configuration pragma file. The following program: 1. package body PSMode is 2.pragma SPARK_Mode (On); 3.procedure q is begin null; end; 4. begin 5.pragma SPARK_Mode (Off); 6.Z := 2; 7. end PSMode; 1. package PSMode is 2.pragma SPARK_Mode (On); 3.X : Integer := 12; 4.Y : Integer := 2 ** X; 5.procedure q; 6. private 7.pragma SPARK_Mode (Off); 8.Z : Integer; 9. end PSMode; compiled with a gnat.adc file that looks like: 1. pragma SPARK_Mode (On); 2. pragma SPARK_Mode (On); gets the following errors compiled with -gnatj60 psmode.adb:2:23: cannot define SPARK mode "on", mode is less restrictive than mode "off" defined at psmode.ads:7 gnat.adc:2:01: pragma "Spark_Mode" duplicates pragma declared at line 1 Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-21 Robert Dewar * atree.ads, atree.adb: Add Node33 and Set_Node33. * einfo.ads, einfo.adb (SPARK_Pragma): New field (SPARK_Aux_Pragma): New field (SPARK_Pragma_Inherited): New flag (SPARK_Aux_Pragma_Inherited): New flag (SPARK_Mode_Pragmas): Removed. * lib.ads, lib.adb: Remove SPARK_Mode_Pragma, no longer used. * opt.ads (SPARK_Mode_Pragma): New global variable. * sem.ads: Add Save_SPARK_Mode_Pragma field to Scope_Stack_Entry. * sem_ch3.adb: Use new SPARK_Mode data structures. * sem_ch6.adb: Set SPARK_Mode fields in subprogram specs and bodies. * sem_ch7.adb: Set SPARK_Mode fields in package spec and body entities. * sem_ch8.adb (Push_Scope): Save SPARK_Mode_Pragma. (Pop_Scope): Restore SPARK_Mode_Pragma. * sem_prag.adb (Analyze_Pragma, case SPARK_Mode): Rewrite for new data structures. Index: atree.adb === --- atree.adb (revision 206872) +++ atree.adb (working copy) @@ -2595,6 +2595,12 @@ return Node_Id (Nodes.Table (N + 5).Field8); end Node32; + function Node33 (N : Node_Id) return Node_Id is + begin + pragma Assert (Nkind (N) in N_Entity); + return Node_Id (Nodes.Table (N + 5).Field9); + end Node33; + function List1 (N : Node_Id) return List_Id is begin pragma Assert (N <= Nodes.Last); @@ -5336,6 +5342,12 @@ Nodes.Table (N + 5).Field8 := Union_Id (Val); end Set_Node32; + procedure Set_Node33 (N : Node_Id; Val : Node_Id) is + begin + pragma Assert (Nkind (N) in N_Entity); + Nodes.Table (N + 5).Field9 := Union_Id (Val); + end Set_Node33; + procedure Set_List1 (N : Node_Id; Val : List_Id) is begin pragma Assert (N <= Nodes.Last); Index: atree.ads === --- atree.ads (revision 206872) +++ atree.ads (working copy) @@ -1209,6 +1209,9 @@ function Node32 (N : Node_Id) return Node_Id; pragma Inline (Node32); + function Node33 (N : Node_Id) return Node_Id; + pragma Inline (Node33); + function List1 (N : Node_Id) return List_Id; pragma Inline (List1); @@ -2509,6 +2512,9 @@ procedure Set_Node32 (N : Node_Id; Val : Node_Id); pragma Inline (Set_Node32); + procedure Set_Node33 (N : Node_Id; Val : Node_Id); + pragma Inline (Set_Node33); + procedure Set_List1 (N : Node_Id; Val : List_Id); pragma Inline (Set_List1); Index: einfo.adb === --- einfo.adb (revision 206832) +++ einfo.adb (working copy) @@ -248,9 +248,9 @@ --Thunk_EntityNode31 - --SPARK_Mode_Pragmas Node32 + --SPARK_PragmaNode32 - --(unused)Node33 + --SPARK_Aux_PragmaNode33 --(unused)Node34 @@ -554,9 +554,9 @@ --May_Inherit_Delayed_Rep_Aspects Flag262 --Has_Visible_Refinement Flag263 --Has_Body_References Flag264 + --SPARK_Pragma_Inherited Flag265 + --SPARK_Aux_Pragma_Inherited Flag266 - --(unused)Flag265 - --(unused)Flag266 --(unused)Flag267 --(unused)Flag268 --(unused)Flag269 @@ -2835,9 +2835,27 @@ return Ureal21 (Id); end Small_Value; - function SPA
Re: RFC Asan instrumentation control
> On x86_64-apple-darwin1* the test c-c++-common/asan/use-after-return-1.c (new at r206458) fails. Yes, unfortunately I forgot about this. The patch makes sense. Should I commit it to fix this bug? -Maxim
RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals
Hi, since there was no progress in the last 2 months on that matter, and we are quite late in Phase 3 now, I dare to propose an alternative, very simple solution for this bug now. It does not try to improve or degade the perfomance at all, instead it simply detects binary files with embedded NULs and stops parsing at that point. Boot-strapped and regression-tested on X86_64-linux-gnu. Ok for trunk? Bernd. On Thu, 14 Nov 2013 15:01:59, Dodji Seketeli wrote: > > Jakub Jelinek writes: > >> On Tue, Nov 12, 2013 at 04:33:41PM +0100, Dodji Seketeli wrote: >>> + >>> + memmove (*line, l, len); >>> + (*line)[len - 1] = '\0'; >>> + *line_len = --len; >> >> Shouldn't this be testing that len> 0 && (*line)[len - 1] == '\n' >> first before you decide to overwrite it and decrement len? > > That code above is in a if (len> 0) block. So checking that condition > again is not necessary. Also, I think we don't need to test there is a > terminal '\n' at the end because get_next_line always return the line > content followed either by a '\n' or by a "junk byte" that is right > after the last byte of the file -- in case we reach end of file w/o > seeing a '\n'. > >> Though in that case there would be no '\0' termination of the string >> for files not ending in a new-line. So, either get_next_line should >> append '\n' to the buffer, or you should have there space for that, or >> you can't rely on zero termination of the string and need to use just >> the length. > > OK, I am settling for doing away with the '\0' altogether. > > The patch below makes get_next_line always point to the last character > of the line before the '\n' when it is present. So '\n' is never > counted int the string. I guess that's less confusing to people. > > Tested on x86_64-unknown-linux-gnu against trunk. > > libcpp/ChangeLog: > > * include/line-map.h (linemap_get_file_highest_location): Declare > new function. > * line-map.c (linemap_get_file_highest_location): Define it. > > gcc/ChangeLog: > > * input.h (location_get_source_line): Take an additional line_size > parameter. > (void diagnostics_file_cache_fini): Declare new function. > * input.c (struct fcache): New type. > (fcache_tab_size, fcache_buffer_size, fcache_line_record_size): > New static constants. > (diagnostic_file_cache_init, total_lines_num) > (lookup_file_in_cache_tab, evicted_cache_tab_entry) > (add_file_to_cache_tab, lookup_or_add_file_to_cache_tab) > (needs_read, needs_grow, maybe_grow, read_data, maybe_read_data) > (get_next_line, read_next_line, goto_next_line, read_line_num): > New static function definitions. > (diagnostic_file_cache_fini): New function. > (location_get_source_line): Take an additional output line_len > parameter. Re-write using lookup_or_add_file_to_cache_tab and > read_line_num. > * diagnostic.c (diagnostic_finish): Call > diagnostic_file_cache_fini. > (adjust_line): Take an additional input parameter for the length > of the line, rather than calculating it with strlen. > (diagnostic_show_locus): Adjust the use of > location_get_source_line and adjust_line with respect to their new > signature. While displaying a line now, do not stop at the first > null byte. Rather, display the zero byte as a space and keep > going until we reach the size of the line. > * Makefile.in: Add vec.o to OBJS-libcommon > > gcc/testsuite/ChangeLog: > > * c-c++-common/cpp/warning-zero-in-literals-1.c: New test file. > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204453 > 138bc75d-0d04-0410-961f-82ee72b054a4 > --- > gcc/Makefile.in | 3 +- > gcc/diagnostic.c | 19 +- > gcc/diagnostic.h | 1 + > gcc/input.c | 633 - > gcc/input.h | 5 +- > .../c-c++-common/cpp/warning-zero-in-literals-1.c | Bin 0 -> 240 bytes > libcpp/include/line-map.h | 8 + > libcpp/line-map.c | 40 ++ > 8 files changed, 670 insertions(+), 39 deletions(-) > create mode 100644 gcc/testsuite/c-c++-common/cpp/warning-zero-in-literals-1.c > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index 49285e5..9fe9060 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -1469,7 +1469,8 @@ OBJS = \ > > # Objects in libcommon.a, potentially used by all host binaries and with > # no target dependencies. > -OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o > input.o version.o > +OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o \ > + vec.o input.o version.o > > # Objects in libcommon-target.a, used by drivers and by the core > # compiler and containing target-dependent code. > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c > index 36094a1..6c83f03 100644 > --- a/gcc/diagnostic.c > +++ b/gcc/diagnostic.c > @@ -176,6 +176,8 @@ diagnostic_finish (diagnostic_context *context) > progname); > pp_newline_and_flush (context->printer); > } > + > + diagnostic_file_cache_fini (); > } > > /* Initialize DIAGNOSTIC, where the message MSG has already been > @@ -259,12 +261,13 @@ diagnostic_build_prefix (diagnostic_context *context, > MAX_WIDTH by some margin, then
Re: RFC Asan instrumentation control
On Tue, Jan 21, 2014 at 04:14:23PM +0400, Maxim Ostapenko wrote: > > On x86_64-apple-darwin1* the test > c-c++-common/asan/use-after-return-1.c (new at r206458) fails. > > Yes, unfortunately I forgot about this. The patch makes sense. > > Should I commit it to fix this bug? Patches should be posted to gcc-patches. Jakub
Re: [PATCH, committed] Fix PR 57422
On 23.12.2013 10:52, Andrey Belevantsev wrote: Hello, As described in the PR, the ICE reason was the typo made when introducing calls to add_hard_reg_set. Fixed by the first attached patch, bootstrapped and tested on both ia64 and x86_64, committed as obvious. The test case is very sensitive to the scheduler decisions (e.g. it didn't fail on trunk but only on the revision reported for me), so instead of adding the test I have put in the code two asserts checking that we can always schedule the fence instruction as is. This hunk was tested together with the first but committed separately. The first patch can be safely committed to 4.8, the second can stay on trunk only. Jakub, will it be fine with you? Now the first hunk is also committed to 4.8 and 4.7. Andrey
[C++ Patch] PR 58980
Hi,
in this relatively serious ICE on invalid regression (we don't emit any
sensible diagnostic before ICE-ing) the problem is that is_ancestor
simply asserts that the second argument can be only a NAMESPACE_DECL or
a CLASS_TYPE_P, whereas in the erroneous input at issue it's a
TYPENAME_TYPE. Thus the idea of not calling is_ancestor at all in this
case + adjusting the two error_at calls to use %qT instead of %qD
(dump_type can handle a NAMESPACE_DECL whereas dump_type can't handle a
TYPENAME_TYPE).
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2014-01-21 Paolo Carlini
PR c++/58980
* parser.c (cp_parser_enum_specifier): Handle TYPENAME_TYPE as
nested_name_specifier.
/testsuite
2014-01-21 Paolo Carlini
PR c++/58980
* g++.dg/parse/enum11.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 206875)
+++ cp/parser.c (working copy)
@@ -15471,16 +15471,19 @@ cp_parser_enum_specifier (cp_parser* parser)
/* If that scope does not contain the scope in which the
class was originally declared, the program is invalid. */
- if (prev_scope && !is_ancestor (prev_scope, nested_name_specifier))
+ if (prev_scope
+ && (TREE_CODE (nested_name_specifier) == TYPENAME_TYPE
+ || !is_ancestor (prev_scope, nested_name_specifier)))
{
if (at_namespace_scope_p ())
error_at (type_start_token->location,
"declaration of %qD in namespace %qD which does not "
- "enclose %qD",
+ "enclose %qT",
type, prev_scope, nested_name_specifier);
else
error_at (type_start_token->location,
- "declaration of %qD in %qD which does not enclose
%qD",
+ "declaration of %qD in %qD which does not "
+ "enclose %qT",
type, prev_scope, nested_name_specifier);
type = error_mark_node;
}
Index: testsuite/g++.dg/parse/enum11.C
===
--- testsuite/g++.dg/parse/enum11.C (revision 0)
+++ testsuite/g++.dg/parse/enum11.C (working copy)
@@ -0,0 +1,6 @@
+// PR c++/58980
+
+template struct A
+{
+ enum A::B::C {}; // { dg-error "does not enclose" }
+};
Re: [PATCH] Fix PR59890, improve var-tracking compile-time
On Jan 20, 2014, Jakub Jelinek wrote:
> On Mon, Jan 20, 2014 at 06:24:36PM -0200, Alexandre Oliva wrote:
>> But I think this one is wrong.
>> if (var->onepart == ONEPART_VALUE)
>> {
>> if (local_get_addr_cache == NULL)
>> return;
> But when local_get_addr_cache is non-NULL, no matter if we find a slot there
> or don't, we still fall thru into the 3 loops etc.
Uhh, yes indeed... Evidently I imagined a return at the end of this
if :-/
The patch is good then; but what is my review worth after barfing like
that? :-D
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Toolchain Engineer
Re: RFC Asan instrumentation control
> Patches should be posted to gcc-patches.
>From pr59897
--- ../_clean/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
2014-01-09 10:14:04.0 +0100
+++ gcc/testsuite/c-c++-common/asan/use-after-return-1.c2014-01-09
15:51:04.0 +0100
@@ -48,6 +48,6 @@ int main(int argc, char **argv) {
}
/* { dg-output "WRITE of size 1 at .* thread T0.*" } */
-/* { dg-output "#0.*Func2.*use-after-return-1.c:31.*" } */
+/* { dg-output "#0.*(Func2)?.*use-after-return-1.(c:31)?.*" } */
/* { dg-output "is located in stack of thread T0 at offset.*" } */
/* { dg-output "\'local\' <== Memory access at offset 32 is inside this
variable" } */
but there is probably a better way to do it.
[r
I am leaving for a week with very limited access to the net. Feel free to do
what you think suitable.
TIA
Dominique
Re: [PATCH AArch64_BE 1/4] Big-Endian lane numbering fix
On 16 January 2014 11:49, Alex Velenko wrote: > Hi, > This patch is the first patch in a series of patches fixing Big-Endian > lane numbering. The goal of this series of patches is to make proper > bridge between pure GCC big-endian view on lane numbering and internal > architected view. OK /Marcus
Re: [PATCH AArch64_BE 2/4] Big-Endian lane numbering fix
On 16 January 2014 11:49, Alex Velenko wrote: > Hi, > This patch changes get_lane intrinsics to provide a correct big-endian > indexing. This fixes numerous BE load and store issues based on getting > correct lane. > > Is this good for trunk? OK /Marcus
Re: [PATCH AArch64_BE 3/4] Big-Endian lane numbering fix
On 16 January 2014 11:50, Alex Velenko wrote: > Hi, > > This patch by James Greenhalgh fixes "by-lane" patterns broken by > previous patches. > > > Regression tested on aarch64-none-elf and aarch64_be-none-elf > with no unexpected issues. > > OK? > OK /Marcus
Re: [PATCH AArch64_BE 4/4] Big-Endian lane numbering fix
2014/1/16 Alex Velenko : > Hi, > In previous BE patches the way lane indexing in lanes is calculated has > been changed. To accommodate the change, arm neon intrinsics had to be > updated. > > Is it okay? OK /Marcus
Re: [Patch,AArch64] Support SISD variants of SCVTF,UCVTF
On 13 January 2014 19:27, Vidya Praveen wrote: > Hello, > > This patch adds support to the SISD variants of SCVTF/UCVTF instructions. > This also refactors the existing support for floating point instruction > variants of SCVTF/UCVTF in order to direct the instruction selection based > on the constraints. Given that the floating-point variations supports > inequal width convertions (SI to DF and DI to SF), new mode iterator w1 and > w2 have been introduced and fcvt_target,FCVT_TARGET have been extended to > support non vector type. Since this patch changes the existing patterns, the > testcase includes tests for both SISD and floating point variations of the > instructions. > > Tested for aarch64-none-elf. > > OK for trunk? OK but wait for stage-1. /Marcus
[PATCH] Fix use-after-return-1.c
Hi,
This patch fixes c-c++-common/asan/use-after-return-1.c not to fail on
darwin target (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897).
Ok to commit?
-Maxim.
2014-01-21 Dominique Dhumieres
* c-c++-common/asan/use-after-return-1.c: Fixed
to pass on darwin.
diff --git a/gcc/testsuite/c-c++-common/asan/use-after-return-1.c b/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
index 435637d..49933e5 100644
--- a/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
+++ b/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
@@ -48,6 +48,6 @@ int main(int argc, char **argv) {
}
/* { dg-output "WRITE of size 1 at .* thread T0.*" } */
-/* { dg-output "#0.*Func2.*use-after-return-1.c:31.*" } */
+/* { dg-output "#0.*(Func2)?.*use-after-return-1.(c:31)?.*" } */
/* { dg-output "is located in stack of thread T0 at offset.*" } */
/* { dg-output "\'local\' <== Memory access at offset 32 is inside this variable" } */
Re: [PATCH][AVX512] Add forgotten intrinsics.
On Tue, Jan 21, 2014 at 2:42 PM, Ilya Tocar wrote:
> I found out that we forgot to implement some of AVX512 intrinsics.
> Here is a patch that adds them. Sorry for huge patch, but changes are
> mostly trivial.
> Ok for trunk?
> +(define_insn "avx512f_2_mask_store"
> + [(set (match_operand:PMOV_DST_MODE 0 "nonimmediate_operand" "=m")
> +(vec_merge:PMOV_DST_MODE
> + (any_truncate:PMOV_DST_MODE
> +(match_operand: 1 "register_operand" "v"))
> + (match_dup 0)
> + (match_operand: 2 "register_operand" "k")))]
> + "TARGET_AVX512F"
> + "vpmov\t{%1, %0%{%2%}|%0%{%2%}, %1}"
> + [(set_attr "type" "ssemov")
> + (set_attr "memory" "store")
> + (set_attr "prefix" "evex")
> + (set_attr "mode" "")])
This is the same as the second alternative of the
avx512f_2_mask pattern. Please change the above
into an expander to reuse existing pattern.
Uros.
Re: [RFC][gomp4] Offloading patches (1/3): Add '-fopenmp_target' option
On 12/17/2013 12:35 PM, Michael V. Zolotukhin wrote: Here is a set of patches implementing one more piece of offloading support in GCC. These three patches allow to build a host binary with target image and all tables embedded. Along with patches for libgomp and libgomp plugin, which hopefully will be sent soon, that gives a functional and runnable executable (or DSO) with actual offloading to MIC. Do you have a testcase that can be used to see what this does in action? Bernd
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
Hi Richard, I'd like to get some more of your thoughts on the ABI implications of MSA. Generally, any thoughts you have (or anyone else) on the current state of MIPS ABIs would be welcome. As an example I'm curious whether you see variations of O32 as being new ABIs or extensions of O32, it can be seen as a fine line. The MSA patch as submitted is another variation of O32 ABI which could be described as O32+FP64+MSA(+nan2008) and would be link incompatible with both O32 and O32+FP64(+/-nan2008). The same of course applies to N32/N64 being link incompatible with N32/N64+FP64. This may make it difficult to have a small part of an application optimised with MSA but the rest of the code ignorant of MSA, in your experience do you think that will be an issue? We (MIPS) have several discussions ongoing regarding ABIs on a variety of mailing lists so I'm trying to collect as much input as possible to inform future plans. One part of the patch that I don't believe you commented on is the change of stack alignment for both existing O32+FP64 and new O32+FP64+MSA. Did this seem OK? You did however comment on a related change to MIPS_STACK_ALIGN which has similar implications. I've also pasted the other parts of the patch that are ABI related along with your original comments below. > -#define STACK_BOUNDARY (TARGET_NEWABI ? 128 : 64) > +/* Because we want to allow MSA functions and non-MSA functions to > + call + each other and MSA always requires -mfp64, we set stack > + boundary to + 128 bits when newabi or -mfp64. */ > +#define STACK_BOUNDARY \ > + ((TARGET_NEWABI || TARGET_FLOAT64) ? 128 : 64) Thoughts and opinions welcome from all... Regards, Matthew > > @@ -419,11 +423,17 @@ > >/* The number of words passed in registers, rounded up. */ > >unsigned int reg_words; > > > > - /* For EABI, the offset of the first register from GP_ARG_FIRST or > > - FP_ARG_FIRST. For other ABIs, the offset of the first register > > from > > - the start of the ABI's argument structure (see the > > CUMULATIVE_ARGS > > - comment for details). > > + /* If msa_reg_p is true, the offset of the first register from > > + MSA_ARG_FIRST. > > > > + The value is MAX_ARGS_IN_MSA_REGISTERS if the argument is passed > > +entirely > > + on the stack. > > + > > + If msa_reg_p is false, for EABI, the offset of the first > > +register from > > + GP_ARG_FIRST or FP_ARG_FIRST. For other ABIs, the offset of the > > +first > > + register from the start of the ABI's argument structure > > + (see the CUMULATIVE_ARGS comment for details). > > + > > The value is MAX_ARGS_IN_REGISTERS if the argument is passed > >entirely > > on the stack. */ > >unsigned int reg_offset; > > So the MSA arguments operate outside the normal "argument structure" > for o32, n32 and n64? That's OK with me but please write up what the new > ABI is. > > > @@ -6445,6 +6979,233 @@ > > } > > } > > > > +/* Write a stub for the current function. This stub is used > > + for functions from FR0 to FR1 or from FR1 to FR0. > > + If FR0_TO_FR1_P is true, we need to set the FR mode to 1, > > + set up floating-point arguments, align the stack pointer to 16 > > +bytes, > > + copy the arguments on the stack, call the function, set up the > > +returned > > + floating-point value, and restore the FR mode to 0. > > + If FR0_TO_FR1_P is false, the stub will be similar but we won't > > +need to > > + align the stack pointer to 16 bytes and copy the arguments. */ > > Hmm, what's all this about? > > > > @@ -1410,8 +1436,11 @@ > > /* 8 is observed right on a DECstation and on riscos 4.02. */ > > #define STRUCTURE_SIZE_BOUNDARY 8 > > > > -/* There is no point aligning anything to a rounder boundary than > > this. */ -#define BIGGEST_ALIGNMENT LONG_DOUBLE_TYPE_SIZE > > +/* There is no point aligning anything to a rounder boundary than > > + LONG_DOUBLE_TYPE_SIZE, unless under MSA the bigggest alignment is > > + BITS_PER_MSA_REG. */ > > +#define BIGGEST_ALIGNMENT \ > > + (TARGET_MSA ? BITS_PER_MSA_REG : LONG_DOUBLE_TYPE_SIZE) > > I'm not sure about the ABI implications of this -- will have to think about > it. Please integrate MSA into the comment a bit more rather than tacking it > onto the end. > > > @@ -2293,8 +2372,8 @@ > > /* Treat LOC as a byte offset from the stack pointer and round it up > > to the next fully-aligned offset. */ > > #define MIPS_STACK_ALIGN(LOC) \ > > - (TARGET_NEWABI ? ((LOC) + 15) & -16 : ((LOC) + 7) & -8) > > - > > + ((TARGET_NEWABI || TARGET_FLOAT64) ? \ > > + ((LOC) + 15) & -16 : ((LOC) + 7) & -8) > > What's this about -- again seems dangerous ABIwise.
Re: [C++ Patch] PR 58980
I think I would prefer to change the "child" assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. Jason
Re: [PATCH i386 11/8] [AVX512] [1/2] Rename vmov* intrinsics according to EAS.
Hello,
On 15 Jan 20:53, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 7:13 AM, Kirill Yukhin
> wrote:
> > I have a doubts about changes to sse.md.
> > I've splitted existing (SF-only) patterns into 2: DF and SF.
> > As far as insn operands and final instruction have no such data
> > type discrimination I set this data type to (mem:..) part.
> > Having this (for SF):
> > (define_expand "avx512pf_scatterpfsf"
> > [(unspec
> >[(match_operand: 0 "register_or_constm1_operand")
> > (mem:SF
> > ...
> >
> > instead of this:
> > (define_expand "avx512pf_scatterpf"
> > [(unspec
> >[(match_operand: 0 "register_or_constm1_operand")
> > (mem:
> > ...
> >
> > Not sure if this (DI/SI) mode for mem is needed. Moreover, not sure what
> > that data type represents.
>
> Did you try to add DF/SF mode to the unspec? I am not familiar with
> this insn, but shouldn't the mode of mem access be somehow similar to
> the avx512f_scattersi access?
>
> Also, you can use double macroization with MODEF iterator for SF and DFmode.
It seems that patch is (at last!) non-trivial, so I am splitting out trivial
part
in order to reduce volume.
It is in the bottom.
Bootstrapped, avx-512* tests pass, sse-* tests pass. Ok for trunk?
--
Thanks, K
---
gcc/config/i386/avx512fintrin.h | 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-1.c | 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-2.c | 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vpcmpd-2.c| 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vpcmpq-2.c| 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vpcmpud-2.c | 4 ++--
gcc/testsuite/gcc.target/i386/avx512f-vpcmpuq-2.c | 4 ++--
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/gcc/config/i386/avx512fintrin.h b/gcc/config/i386/avx512fintrin.h
index 26f8cb6..4e94174 100644
--- a/gcc/config/i386/avx512fintrin.h
+++ b/gcc/config/i386/avx512fintrin.h
@@ -5570,7 +5570,7 @@ _mm512_mask_storeu_epi64 (void *__P, __mmask8 __U,
__m512i __A)
extern __inline __m512i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_loadu_si512 (void const *__P)
+_mm512_loadu_epi32 (void const *__P)
{
return (__m512i) __builtin_ia32_loaddqusi512_mask ((const __v16si *) __P,
(__v16si)
@@ -5599,7 +5599,7 @@ _mm512_maskz_loadu_epi32 (__mmask16 __U, void const *__P)
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_storeu_si512 (void *__P, __m512i __A)
+_mm512_storeu_epi32 (void *__P, __m512i __A)
{
__builtin_ia32_storedqusi512_mask ((__v16si *) __P, (__v16si) __A,
(__mmask16) -1);
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-1.c
b/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-1.c
index 79dbf9d..66e358a 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-1.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-1.c
@@ -15,10 +15,10 @@ volatile __mmask16 m;
void extern
avx512f_test (void)
{
- x = _mm512_loadu_si512 (p);
+ x = _mm512_loadu_epi32 (p);
x = _mm512_mask_loadu_epi32 (x, m, p);
x = _mm512_maskz_loadu_epi32 (m, p);
- _mm512_storeu_si512 (p, x);
+ _mm512_storeu_epi32 (p, x);
_mm512_mask_storeu_epi32 (p, m, x);
}
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-2.c
b/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-2.c
index f1ae73c..0333d31 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vmovdqu32-2.c
@@ -33,8 +33,8 @@ TEST (void)
}
#if AVX512F_LEN == 512
- res1.x = _mm512_loadu_si512 (s1.a);
- _mm512_storeu_si512 (res2.a, s2.x);
+ res1.x = _mm512_loadu_epi32 (s1.a);
+ _mm512_storeu_epi32 (res2.a, s2.x);
#endif
res3.x = INTRINSIC (_mask_loadu_epi32) (res3.x, mask, s1.a);
res4.x = INTRINSIC (_maskz_loadu_epi32) (mask, s1.a);
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vpcmpd-2.c
b/gcc/testsuite/gcc.target/i386/avx512f-vpcmpd-2.c
index 600dfd2..c044f42 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-vpcmpd-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vpcmpd-2.c
@@ -17,8 +17,8 @@
{ \
dst_ref = ((rel) << i) | dst_ref;\
} \
-source1.x = _mm512_loadu_si512 (s1); \
-source2.x = _mm512_loadu_si512 (s2); \
+source1.x = _mm512_loadu_epi32 (s1); \
+source2.x = _mm512_loadu_epi32 (s2); \
dst1 = _mm512_cmp_epi32_mask (source1.x, source2.x, imm);\
dst2 = _mm512_mask_cmp_epi32_mask (mask, source1.x, source2.x, imm);\
if (dst_ref != dst1) abort(); \
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vpcmpq-2.c
b/gcc/testsuite/gcc.target/i386/avx512f-vpcmpq-2.c
index 2a9ceb6..e3a90d8 100644
--- a/gcc/t
Re: [C++ PATCH] Emit array initialization from ctor as loop if possible (PR c++/59659)
I'm inclined to handle this situation by using a RANGE_EXPR in process_init_constructor_array, and then handling that appropriately in build_vec_init, so that we don't have to build up the huge CONSTRUCTOR. Would you like to do that, or shall I take it over? Jason
Re: [PATCH i386 11/8] [AVX512] [1/2] Rename vmov* intrinsics according to EAS.
On Tue, Jan 21, 2014 at 4:07 PM, Kirill Yukhin wrote: >> > I have a doubts about changes to sse.md. >> > I've splitted existing (SF-only) patterns into 2: DF and SF. >> > As far as insn operands and final instruction have no such data >> > type discrimination I set this data type to (mem:..) part. >> > Having this (for SF): >> > (define_expand "avx512pf_scatterpfsf" >> > [(unspec >> >[(match_operand: 0 "register_or_constm1_operand") >> > (mem:SF >> > ... >> > >> > instead of this: >> > (define_expand "avx512pf_scatterpf" >> > [(unspec >> >[(match_operand: 0 "register_or_constm1_operand") >> > (mem: >> > ... >> > >> > Not sure if this (DI/SI) mode for mem is needed. Moreover, not sure what >> > that data type represents. >> >> Did you try to add DF/SF mode to the unspec? I am not familiar with >> this insn, but shouldn't the mode of mem access be somehow similar to >> the avx512f_scattersi access? >> >> Also, you can use double macroization with MODEF iterator for SF and DFmode. > > It seems that patch is (at last!) non-trivial, so I am splitting out trivial > part > in order to reduce volume. > > It is in the bottom. > > Bootstrapped, avx-512* tests pass, sse-* tests pass. Ok for trunk? OK with a proper ChangeLog. Thanks, Uros.
Re: [C++ PATCH] Emit array initialization from ctor as loop if possible (PR c++/59659)
On Tue, Jan 21, 2014 at 10:11:45AM -0500, Jason Merrill wrote: > I'm inclined to handle this situation by using a RANGE_EXPR in > process_init_constructor_array, and then handling that appropriately > in build_vec_init, so that we don't have to build up the huge > CONSTRUCTOR. Would you like to do that, or shall I take it over? If you could take it over, I'd appreciate it. Note that the RANGE_EXPR related PR59886 regression is probably higher priority though (and no idea how to handle the cleanup there nicely if some ctor throws during second or following iteration). Jakub
Re: [C++ Patch] PR 58980
Hi,
On 01/21/2014 03:55 PM, Jason Merrill wrote:
I think I would prefer to change the "child" assert to be
MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P.
.. Ok, but then it seems to me that we have to explicitly handle the
TYPENAME_TYPE case, otherwise we end up simply accepting the testcase
(even if the template is instantiated!). Something like the below...
Paolo.
//
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 206880)
+++ cp/name-lookup.c(working copy)
@@ -2723,12 +2723,15 @@ is_ancestor (tree root, tree child)
|| TREE_CODE (root) == FUNCTION_DECL
|| CLASS_TYPE_P (root)));
gcc_assert ((TREE_CODE (child) == NAMESPACE_DECL
- || CLASS_TYPE_P (child)));
+ || MAYBE_CLASS_TYPE_P (child)));
/* The global namespace encloses everything. */
if (root == global_namespace)
return true;
+ if (TREE_CODE (child) == TYPENAME_TYPE)
+return false;
+
while (true)
{
/* If we've run out of scopes, stop. */
Index: cp/parser.c
===
--- cp/parser.c (revision 206880)
+++ cp/parser.c (working copy)
@@ -15476,11 +15476,12 @@ cp_parser_enum_specifier (cp_parser* parser)
if (at_namespace_scope_p ())
error_at (type_start_token->location,
"declaration of %qD in namespace %qD which does not "
- "enclose %qD",
+ "enclose %qT",
type, prev_scope, nested_name_specifier);
else
error_at (type_start_token->location,
- "declaration of %qD in %qD which does not enclose
%qD",
+ "declaration of %qD in %qD which does not "
+ "enclose %qT",
type, prev_scope, nested_name_specifier);
type = error_mark_node;
}
Index: testsuite/g++.dg/parse/enum11.C
===
--- testsuite/g++.dg/parse/enum11.C (revision 0)
+++ testsuite/g++.dg/parse/enum11.C (working copy)
@@ -0,0 +1,6 @@
+// PR c++/58980
+
+template struct A
+{
+ enum A::B::C {}; // { dg-error "does not enclose" }
+};
Re: [C++ patch] PR 59482
OK, thanks. Jason
[C++ patch] PR 59482
As analysed in the bug report, the scope for the accessibility
check was incorrect, and hence the friend was not allowed access.
Fixed by pushing into the class scope before parsing the
base-clause, and popping afterwards to let the surrounding
nested-name-specifier popping work correctly.
Tested on x86_64-linux.
pr59482.changelog
Description: Binary data
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c3016bc..3bc943b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -19845,7 +19845,17 @@ cp_parser_class_head (cp_parser* parser,
/* Get the list of base-classes, if there is one. */
if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
-bases = cp_parser_base_clause (parser);
+{
+ /* PR59482: enter the class scope so that base-specifiers are looked
+ up correctly */
+ if (type)
+ pushclass (type);
+ bases = cp_parser_base_clause (parser);
+ /* PR59482: get out of the previously pushed class scope so that the
+ subsequent pops pop the right thing */
+ if (type)
+ popclass ();
+}
else
bases = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/pr59482.C b/gcc/testsuite/g++.dg/pr59482.C
new file mode 100644
index 000..bde8329
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr59482.C
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+class aa {
+friend class cc;
+class bb {};
+};
+
+class cc : aa::bb {};
Re: Fix a dbr_schedule vs. delete_related_insns liveness bug
On 01/18/14 03:12, Richard Sandiford wrote: Jeff Law writes: gcc/ * jump.c (delete_related_insns): Keep (use (insn))s. * reorg.c (redundant_insn): Check for barriers too. OK. Any chance you've got a testcase you can add to the suite? ISTM it's potentially valuable given the plan to remove barriers and the implications that has for reorg.c liveness tracking. Applied, thanks. I spent a few hours trying to reduce the testcase to something that was likely to show the problem reliably, but it looks like a lot of things have to happen in just the right (or wrong) way. One of the problems is that if we have: barrier L1: A B and turn it into: barrier L2: B find_basic_block will not have a basic block for the new label L2 and we won't get a liveness set at all. So we need a case where we've cached the find_basic_block result from before the transformation. This happens in the original testcase because we only introduce the label during the second reorg pass, but I'm finding it hard to force cases that can only trigger during the second pass. The original problem showed up as the tree-prof failures here: http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00633.html but unfortunately that needs a mips64-linux-gnu rather than gdbsim environment to reproduce. Thanks for taking the time to try and pull something together. I've certainly got no objections to this going forward without a regression test. Thanks, Jeff
Patch committed: Fix ChangeLog entry
This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that was incorrectly added to the top-level ChangeLog file. Changes to ChangeLog files do not themselves get ChangeLog entries. Committed as obvious. Ian Index: ChangeLog === --- ChangeLog (revision 206892) +++ ChangeLog (working copy) @@ -3,10 +3,6 @@ * MAINTAINERS: Convert to UTF-8. Properly sort Xinliang David Li's entry. -2014-01-19 Kito Cheng - - * gcc/builtins.c (expand_movstr): Check movstr expand done or fail. - 2013-12-31 Chung-Lin Tang Sandra Loosemore Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206892) +++ gcc/ChangeLog (working copy) @@ -123,6 +123,10 @@ * config/vax/vax.h (FUNCTION_ARG_REGNO_P): Fix unused variable warning. +2014-01-19 Kito Cheng + + * builtins.c (expand_movstr): Check movstr expand done or fail. + 2014-01-18 Uros Bizjak H.J. Lu
[PATCH,rs6000] Add tests for vec_insert and vec_extract implemented with VSX instructions
Hi,
A previous patch of mine implemented support for -maltivec=be for little
endian targets when expanding the vec_insert and vec_extract builtins.
However, I neglected to include test cases for V2DI and V2DF, which are
implemented using VSX instructions and therefore need different compile
options. This patch adds those tests, which pass for
powerpc64{,le}-unknown-linux-gnu without further changes to GCC. Ok for
trunk?
Thanks,
Bill
2014-01-21 Bill Schmidt
* gcc.dg/vmx/insert-vsx-be-order.c: New.
* gcc.dg/vmx/extract-vsx.c: New.
* gcc.dg/vmx/extract-vsx-be-order.c: New.
* gcc.dg/vmx/insert-vsx.c: New.
Index: gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/insert-vsx-be-order.c (revision 0)
@@ -0,0 +1,34 @@
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-maltivec=be -mabi=altivec -std=gnu99 -mvsx" } */
+
+#include "harness.h"
+
+static int vec_long_eq (vector long x, vector long y)
+{
+ return (x[0] == y[0] && x[1] == y[1]);
+}
+
+static int vec_dbl_eq (vector double x, vector double y)
+{
+ return (x[0] == y[0] && x[1] == y[1]);
+}
+
+static void test()
+{
+ vector long vl = {0, 1};
+ vector double vd = {0.0, 1.0};
+ vector long vlr = vec_insert (2, vl, 0);
+ vector double vdr = vec_insert (2.0, vd, 1);
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ vector long vler = {0, 2};
+ vector double vder = {2.0, 1.0};
+#else
+ vector long vler = {2, 1};
+ vector double vder = {0.0, 2.0};
+#endif
+
+ check (vec_long_eq (vlr, vler), "vl");
+ check (vec_dbl_eq (vdr, vder), "vd");
+}
Index: gcc/testsuite/gcc.dg/vmx/extract-vsx.c
===
--- gcc/testsuite/gcc.dg/vmx/extract-vsx.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/extract-vsx.c (revision 0)
@@ -0,0 +1,16 @@
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-maltivec -mabi=altivec -std=gnu99 -mvsx" } */
+
+#include "harness.h"
+
+static void test()
+{
+ vector long vl = {0, 1};
+ vector double vd = {0.0, 1.0};
+
+ check (vec_extract (vl, 0) == 0, "vec_extract, vl, 0");
+ check (vec_extract (vd, 1) == 1.0, "vec_extract, vd, 1");
+ check (vl[0] == 0, "[], vl, 0");
+ check (vd[1] == 1.0, "[], vd, 0");
+}
Index: gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/extract-vsx-be-order.c (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-maltivec=be -mabi=altivec -std=gnu99 -mvsx" } */
+
+#include "harness.h"
+
+static void test()
+{
+ vector long vl = {0, 1};
+ vector double vd = {0.0, 1.0};
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ check (vec_extract (vl, 0) == 1, "vl, 0");
+ check (vec_extract (vd, 1) == 0.0, "vd, 1");
+#else
+ check (vec_extract (vl, 0) == 0, "vl, 0");
+ check (vec_extract (vd, 1) == 1.0, "vd, 1");
+#endif
+}
Index: gcc/testsuite/gcc.dg/vmx/insert-vsx.c
===
--- gcc/testsuite/gcc.dg/vmx/insert-vsx.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/insert-vsx.c (revision 0)
@@ -0,0 +1,28 @@
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-maltivec -mabi=altivec -std=gnu99 -mvsx" } */
+
+#include "harness.h"
+
+static int vec_long_eq (vector long x, vector long y)
+{
+ return (x[0] == y[0] && x[1] == y[1]);
+}
+
+static int vec_dbl_eq (vector double x, vector double y)
+{
+ return (x[0] == y[0] && x[1] == y[1]);
+}
+
+static void test()
+{
+ vector long vl = {0, 1};
+ vector double vd = {0.0, 1.0};
+ vector long vlr = vec_insert (2, vl, 0);
+ vector double vdr = vec_insert (2.0, vd, 1);
+ vector long vler = {2, 1};
+ vector double vder = {0.0, 2.0};
+
+ check (vec_long_eq (vlr, vler), "vl");
+ check (vec_dbl_eq (vdr, vder), "vd");
+}
Re: Patch committed: Fix ChangeLog entry
Ian Lance Taylor writes: > This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that > was incorrectly added to the top-level ChangeLog file. Changes to > ChangeLog files do not themselves get ChangeLog entries. Committed as > obvious. Sorry, this was my bad, not Kito's fault at all. Richard
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
On Tue, 21 Jan 2014, Matthew Fortune wrote: > The MSA patch as submitted is another variation of O32 ABI which could > be described as O32+FP64+MSA(+nan2008) and would be link incompatible > with both O32 and O32+FP64(+/-nan2008). The same of course applies to > N32/N64 being link incompatible with N32/N64+FP64. This may make it > difficult to have a small part of an application optimised with MSA but > the rest of the code ignorant of MSA, in your experience do you think > that will be an issue? In general, unnecessary ABI incompatibility is to be discouraged. This means (I'm talking about all architectures, not just MIPS): * Use dynamic stack realignment rather than increasing the alignment assumed by callees. * New registers should be call-clobbered, so setjmp/longjmp (and *context functions) don't need to save and preserve them. * Do not change layout or alignment of existing types. * If your architecture defines that some ISA feature can only coexist with other ISA features (for example, that it can only coexist with hardware floating point, or only with 64-bit support) then that may reduce the number of ABI variants that need to be defined. * If you want to pass vector arguments (or return values) in new registers, without affecting the ABI for any non-vector argument or return type, we're a bit more relaxed on that - but if this affects GNU C generic vectors rather than just architecture-specific vector types there should, at least, be a -Wpsabi warning about the ABI change implied by enabling the vector instructions. Alternatively, enable such argument passing only with an ABI option e.g. -mmsa-abi, rather than with the same option that enables the new instructions. In either case, you need to make sure the dynamic linker is built with the new instructions disabled, to avoid it clobbering the new registers (just as it generally needs special handling for call-clobbered registers involved in argument passing). * In any case, write an ABI document at an early stage that documents how the new registers interact with the ABI. If you do conclude that you need a new, incompatible ABI, then the following also apply - see the NaN2008 changes for recent MIPS examples: * Ensure the static linker gives errors for linking incompatible objects (whether with GNU object attributes, ELF header bits, or some other mechanism). * For glibc, define new dynamic linker names (see recent discussion on the glibc lists) and ensure the corresponding specs in GCC pass the right arguments to -dynamic-linker. * Ensure that glibc can tell executables / shared libraries for the different ABIs apart by examining the ELF header, ensure elf_machine_matches_host checks compatibility, and ensure ldconfig handles the different kinds of executables / shared libraries (_DL_CACHE_DEFAULT_ID, readelflib.c:process_elf_file, etc.). -- Joseph S. Myers jos...@codesourcery.com
[C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
In this PR the problem was that the C FE, unlike the C++ FE, didn't
warn on e.g. bar (), 1;, that the RHS has no effect. This patch tries
to tweak the C FE so that it follows what the C++ FE does. Note that
the C++ FE uses quite imprecise locus info; the C FE's info is better.
I had to slightly adjust one testcase and a header in libdecnumber.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-01-21 Marek Polacek
PR c/59871
c/
* c-typeck.c (build_compound_expr): Warn even for right-hand operand
of comma expression.
(emit_side_effect_warnings): Likewise.
libdecnumber/
* decNumberLocal.h (UBFROMUS, UBFROMUI): Cast last argument to void.
testsuite/
* gcc.dg/20020220-2.c: Adjust dg-warning message.
* gcc.dg/pr59871.c: New test.
--- gcc/libdecnumber/decNumberLocal.h.mp2014-01-21 18:34:32.235540589
+0100
+++ gcc/libdecnumber/decNumberLocal.h 2014-01-21 19:04:12.173243034 +0100
@@ -155,8 +155,10 @@ see the files COPYING3 and COPYING.RUNTI
/* Store a uInt, etc., into bytes starting at a char* or uByte*.*/
/* Returns i, evaluated, for convenience; has to use uiwork because */
/* i may be an expression. */
- #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), uswork)
- #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), uiwork)
+ #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), \
+ (void)uswork)
+ #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), \
+ (void)uiwork)
/* X10 and X100 -- multiply integer i by 10 or 100 */
/* [shifts are usually faster than multiply; could be conditional] */
--- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
+++ gcc/gcc/c/c-typeck.c2014-01-21 18:10:53.900279750 +0100
@@ -4757,6 +4757,18 @@ build_compound_expr (location_t loc, tre
expr2 = TREE_OPERAND (expr2, 0);
}
+ if (TREE_CODE (expr1) == COMPOUND_EXPR
+ && warn_unused_value)
+{
+ tree r = expr1;
+ while (TREE_CODE (r) == COMPOUND_EXPR)
+r = TREE_OPERAND (r, 1);
+ if (!TREE_SIDE_EFFECTS (r)
+ && !VOID_TYPE_P (TREE_TYPE (r))
+ && !CONVERT_EXPR_P (r))
+ warning_at (loc, OPT_Wunused_value,
+ "right-hand operand of comma expression has no effect");
+}
if (!TREE_SIDE_EFFECTS (expr1))
{
/* The left-hand operand of a comma expression is like an expression
@@ -9641,6 +9653,18 @@ emit_side_effect_warnings (location_t lo
if (!VOID_TYPE_P (TREE_TYPE (expr)) && !TREE_NO_WARNING (expr))
warning_at (loc, OPT_Wunused_value, "statement with no effect");
}
+ else if (TREE_CODE (expr) == COMPOUND_EXPR)
+{
+ tree r = expr;
+ while (TREE_CODE (r) == COMPOUND_EXPR)
+r = TREE_OPERAND (r, 1);
+ if (!TREE_SIDE_EFFECTS (r)
+ && !VOID_TYPE_P (TREE_TYPE (r))
+ && !CONVERT_EXPR_P (r)
+ && !TREE_NO_WARNING (expr))
+ warning_at (EXPR_LOC_OR_LOC (expr, loc), OPT_Wunused_value,
+ "right-hand operand of comma expression has no effect");
+}
else
warn_if_unused_value (expr, loc);
}
--- gcc/gcc/testsuite/gcc.dg/20020220-2.c.mp2014-01-21 14:47:58.888754509
+0100
+++ gcc/gcc/testsuite/gcc.dg/20020220-2.c 2014-01-21 15:04:53.700441224
+0100
@@ -1,5 +1,5 @@
/* PR c/4697
- Test whether value computed not used warning is given for compound
+ Test whether operand has no effect warning is given for compound
expression. */
/* { dg-do compile } */
/* { dg-options "-O2 -Wunused" } */
@@ -7,6 +7,6 @@
int b;
int foo (int a)
{
- a = a + 1, 5 * b;/* { dg-warning "value computed is not used" } */
+ a = a + 1, 5 * b; /* { dg-warning "right operand of comma operator has no
effect" } */
return a;
}
--- gcc/gcc/testsuite/gcc.dg/pr59871.c.mp 2014-01-21 16:17:49.0
+0100
+++ gcc/gcc/testsuite/gcc.dg/pr59871.c 2014-01-21 16:13:39.0 +0100
@@ -0,0 +1,15 @@
+/* PR c/59871 */
+/* { dg-do compile } */
+/* { dg-options "-Wunused" } */
+
+extern int bar ();
+
+void
+foo (int *p)
+{
+ p[0] = (bar (), 1, bar ()); /* { dg-warning "right-hand operand of comma
expression has no effect" } */
+ p[1] = (1, bar ()); /* { dg-warning "left-hand operand of comma expression
has no effect" } */
+ bar (), 1, bar (); /* { dg-warning "right-hand operand of comma expression
has no effect" } */
+ bar (), 1; /* { dg-warning "right-hand operand of comma expression has no
effect" } */
+ 1, bar (); /* { dg-warning "left-hand operand of comma expression has no
effect" } */
+}
Marek
Re: [PATCH,rs6000] Add tests for vec_insert and vec_extract implemented with VSX instructions
> A previous patch of mine implemented support for -maltivec=be for little
> endian targets when expanding the vec_insert and vec_extract builtins.
> However, I neglected to include test cases for V2DI and V2DF, which are
> implemented using VSX instructions and therefore need different compile
> options. This patch adds those tests, which pass for
> powerpc64{,le}-unknown-linux-gnu without further changes to GCC. Ok for
> trunk?
>
> Thanks,
> Bill
>
>
> 2014-01-21 Bill Schmidt
>
> * gcc.dg/vmx/insert-vsx-be-order.c: New.
> * gcc.dg/vmx/extract-vsx.c: New.
> * gcc.dg/vmx/extract-vsx-be-order.c: New.
> * gcc.dg/vmx/insert-vsx.c: New.
Okay.
Thanks, David
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 07:38:10PM +0100, Marek Polacek wrote:
> --- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
> +++ gcc/gcc/c/c-typeck.c 2014-01-21 18:10:53.900279750 +0100
> @@ -4757,6 +4757,18 @@ build_compound_expr (location_t loc, tre
>expr2 = TREE_OPERAND (expr2, 0);
> }
>
> + if (TREE_CODE (expr1) == COMPOUND_EXPR
> + && warn_unused_value)
> +{
> + tree r = expr1;
> + while (TREE_CODE (r) == COMPOUND_EXPR)
> +r = TREE_OPERAND (r, 1);
> + if (!TREE_SIDE_EFFECTS (r)
> + && !VOID_TYPE_P (TREE_TYPE (r))
> + && !CONVERT_EXPR_P (r))
> + warning_at (loc, OPT_Wunused_value,
> + "right-hand operand of comma expression has no effect");
> +}
>if (!TREE_SIDE_EFFECTS (expr1))
> {
>/* The left-hand operand of a comma expression is like an expression
Won't this warn twice if !TREE_SIDE_EFFECTS (expr1) and expr1 is a
COMPOUND_EXPR? I would be expecting this whole if as else if below the
!TREE_SIDE_EFFECTS case. I mean, in emit_side_effect_warnings you do it
the same way, and if nothing in the expr1 COMPOUND_EXPR has any
!side-effects, then it is ok to complain about the expr1 as whole, no
need to complain particularly about the rhs of it.
Also, shouldn't you use EXPR_LOCATION of the COMPOUND_EXPR r is rhs of
in the end? I.e. do something like:
location_t cloc = loc;
while (TREE_CODE (r) == COMPOUND_EXPR)
{
if (EXPR_HAS_LOCATION (r)) cloc = EXPR_LOCATION (r);
r = TREE_OPERAND (r, 1);
}
and use cloc in warning_at.
Jakub
Re: [PATCH i386 11/8] [AVX512] [2/2] Add missing packed PF gathers/scatters.
Hello,
This is non-trivial part of the patch.
> On 15 Jan 20:53, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 7:13 AM, Kirill Yukhin
> wrote:
> Did you try to add DF/SF mode to the unspec? I am not familiar with
> this insn, but shouldn't the mode of mem access be somehow similar to
> the avx512f_scattersi access?
avx512f_scattersi is different in its appearence.
It has explicit type of destination which discriminates SF/DF modes. Prefetches
has no such.
> Also, you can use double macroization with MODEF iterator for SF and DFmode.
I think I cannot. Because DF/SF types of the insn incurs different vidx
iterators.
E.g.:
Currently we have for SF:
(define_expand "avx512pf_scatterpfsf"
[(unspec
[(match_operand: 0 "register_or_constm1_operand")
(mem:SF
(match_par_dup 5
[(match_operand 2 "vsib_address_operand")
(match_operand:VI48_512 1 "register_operand")
(match_operand:SI 3 "const1248_operand")]))
(match_operand:SI 4 "const_0_to_1_operand")]
UNSPEC_SCATTER_PREFETCH)]
and for DF:
(define_expand "avx512pf_scatterpfdf"
[(unspec
[(match_operand: 0 "register_or_constm1_operand")
(mem:DF
(match_par_dup 5
[(match_operand 2 "vsib_address_operand")
(match_operand:VI4_256_8_512 1 "register_operand")
(match_operand:SI 3 "const1248_operand")]))
(match_operand:SI 4 "const_0_to_1_operand")]
UNSPEC_SCATTER_PREFETCH)]
We have this correspondence between, say, main and index modes:
SF -> (V16SI, V8DI)
DF -> (V8SI , V8DI)
I think we should hear from Jaku about sse.md changes and expansion.
Bootstrapped, avx512* and sse-* tests pass.
Comments?
--
Thanks, K
---
gcc/config/i386/avx512pfintrin.h | 113 --
gcc/config/i386/i386-builtin-types.def | 2 +
gcc/config/i386/i386.c | 37 -
gcc/config/i386/sse.md | 171 +++--
gcc/testsuite/gcc.target/i386/avx-1.c | 4 +
.../gcc.target/i386/avx512pf-vgatherpf0dpd-1.c | 15 ++
.../gcc.target/i386/avx512pf-vgatherpf0qpd-1.c | 15 ++
.../gcc.target/i386/avx512pf-vgatherpf1dpd-1.c | 15 ++
.../gcc.target/i386/avx512pf-vgatherpf1qpd-1.c | 15 ++
.../gcc.target/i386/avx512pf-vscatterpf0dpd-1.c| 17 ++
.../gcc.target/i386/avx512pf-vscatterpf0qpd-1.c| 17 ++
.../gcc.target/i386/avx512pf-vscatterpf1dpd-1.c| 17 ++
.../gcc.target/i386/avx512pf-vscatterpf1qpd-1.c| 17 ++
gcc/testsuite/gcc.target/i386/sse-14.c | 4 +
gcc/testsuite/gcc.target/i386/sse-22.c | 5 +
gcc/testsuite/gcc.target/i386/sse-23.c | 4 +
16 files changed, 437 insertions(+), 31 deletions(-)
diff --git a/gcc/config/i386/avx512pfintrin.h b/gcc/config/i386/avx512pfintrin.h
index b8c0110..bc7598e 100644
--- a/gcc/config/i386/avx512pfintrin.h
+++ b/gcc/config/i386/avx512pfintrin.h
@@ -48,74 +48,157 @@ typedef unsigned short __mmask16;
#ifdef __OPTIMIZE__
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+_mm512_mask_prefetch_i32gather_pd (__m256i index, __mmask8 mask,
+ void *addr, int scale, int hint)
+{
+ __builtin_ia32_gatherpfdpd (mask, (__v8si) index, (long long const *) addr,
+ scale, hint);
+}
+
+extern __inline void
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_prefetch_i32gather_ps (__m512i index, __mmask16 mask,
- int const *addr, int scale, int hint)
+ void *addr, int scale, int hint)
+{
+ __builtin_ia32_gatherpfdps (mask, (__v16si) index, (int const *) addr,
+ scale, hint);
+}
+
+extern __inline void
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+_mm512_mask_prefetch_i64gather_pd (__m512i index, __mmask8 mask,
+ void *addr, int scale, int hint)
{
- __builtin_ia32_gatherpfdps (mask, (__v16si) index, addr, scale, hint);
+ __builtin_ia32_gatherpfqpd (mask, (__v8di) index, (long long const *) addr,
+ scale, hint);
}
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_prefetch_i64gather_ps (__m512i index, __mmask8 mask,
- int const *addr, int scale, int hint)
+ void *addr, int scale, int hint)
{
- __builtin_ia32_gatherpfqps (mask, (__v8di) index, addr, scale, hint);
+ __builtin_ia32_gatherpfqps (mask, (__v8di) index, (int const *) addr,
+ scale, hint);
}
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_prefetch_i32scatter_ps (int const *addr, __m512i index, int scale,
+_mm512_prefetch_i32scatter_pd (void *addr, __m256i index, int scale,
Re: [PATCH AArch64_BE 1/4] Big-Endian lane numbering fix
Hi, Can someone, please, commit this patch as I do not have privileges to do so. Kind regards, Alex Velenko On 21/01/14 13:27, Marcus Shawcroft wrote: On 16 January 2014 11:49, Alex Velenko wrote: Hi, This patch is the first patch in a series of patches fixing Big-Endian lane numbering. The goal of this series of patches is to make proper bridge between pure GCC big-endian view on lane numbering and internal architected view. OK /Marcus
Re: [PATCH AArch64_BE 2/4] Big-Endian lane numbering fix
Hi, Can someone, please, commit this patch as I do not have privileges to do so. Kind regards, Alex Velenko On 21/01/14 13:31, Marcus Shawcroft wrote: On 16 January 2014 11:49, Alex Velenko wrote: Hi, This patch changes get_lane intrinsics to provide a correct big-endian indexing. This fixes numerous BE load and store issues based on getting correct lane. Is this good for trunk? OK /Marcus
Re: [PATCH AArch64_BE 3/4] Big-Endian lane numbering fix
Hi, Can someone, please, commit this patch as I do not have privileges to do so. Kind regards, Alex Velenko On 21/01/14 13:32, Marcus Shawcroft wrote: On 16 January 2014 11:50, Alex Velenko wrote: Hi, This patch by James Greenhalgh fixes "by-lane" patterns broken by previous patches. Regression tested on aarch64-none-elf and aarch64_be-none-elf with no unexpected issues. OK? OK /Marcus
Re: [PATCH AArch64_BE 4/4] Big-Endian lane numbering fix
Hi, Can someone, please, commit this patch as I do not have privileges to do so. Kind regards, Alex Velenko On 21/01/14 13:34, Marcus Shawcroft wrote: 2014/1/16 Alex Velenko : Hi, In previous BE patches the way lane indexing in lanes is calculated has been changed. To accommodate the change, arm neon intrinsics had to be updated. Is it okay? OK /Marcus
[PATCH] Fix up expand_small_movmem_or_setmem (PR target/59003)
Hi!
As the testcase shows, for the memset (x, 0, y); snippet which handles
y from 16 to 31 inclusive for some tunings, we generate:
.L36:
movq$0, (%rdi)
movq$0, 8(%rdi)
movq$0, -8(%rsi,%rdi)
which is correct only for y from 16 to 24 inclusive, if y is 25 to 31,
we clear the first 16 bytes and last 8 bytes of the buffer, but would leave
1 to 7 bytes untouched in between that.
With this patch we emit:
.L36:
movq$0, (%rdi)
movq$0, 8(%rdi)
movq$0, -16(%rsi,%rdi)
movq$0, -8(%rsi,%rdi)
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-01-21 Jakub Jelinek
PR target/59003
* config/i386/i386.c (expand_small_movmem_or_setmem): If mode is
smaller than size, perform several stores or loads and stores
at dst + count - size to store or copy all of size bytes, rather
than just last modesize bytes.
* gcc.dg/tree-prof/pr59003.c: New test.
--- gcc/config/i386/i386.c.jj 2014-01-20 19:12:56.0 +0100
+++ gcc/config/i386/i386.c 2014-01-21 16:46:19.965094839 +0100
@@ -23397,16 +23397,24 @@ expand_small_movmem_or_setmem (rtx destm
}
destmem = offset_address (destmem, count, 1);
- destmem = offset_address (destmem, GEN_INT (-size - GET_MODE_SIZE (mode)),
+ destmem = offset_address (destmem, GEN_INT (-2 * size),
GET_MODE_SIZE (mode));
- if (issetmem)
-emit_move_insn (destmem, gen_lowpart (mode, value));
- else
+ if (!issetmem)
{
srcmem = offset_address (srcmem, count, 1);
- srcmem = offset_address (srcmem, GEN_INT (-size - GET_MODE_SIZE (mode)),
+ srcmem = offset_address (srcmem, GEN_INT (-2 * size),
GET_MODE_SIZE (mode));
- emit_move_insn (destmem, srcmem);
+}
+ for (n = 0; n * GET_MODE_SIZE (mode) < size; n++)
+{
+ if (issetmem)
+ emit_move_insn (destmem, gen_lowpart (mode, value));
+ else
+ {
+ emit_move_insn (destmem, srcmem);
+ srcmem = offset_address (srcmem, modesize, GET_MODE_SIZE (mode));
+ }
+ destmem = offset_address (destmem, modesize, GET_MODE_SIZE (mode));
}
emit_jump_insn (gen_jump (done_label));
emit_barrier ();
--- gcc/testsuite/gcc.dg/tree-prof/pr59003.c.jj 2014-01-21 15:43:58.004385383
+0100
+++ gcc/testsuite/gcc.dg/tree-prof/pr59003.c2014-01-21 15:45:51.0
+0100
@@ -0,0 +1,29 @@
+/* PR target/59003 */
+/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mtune=amdfam10" { target i?86-*-* x86_64-*-* } } */
+
+__attribute__((noinline, noclone)) void *
+foo (void *p, unsigned int q)
+{
+ return __builtin_memset (p, 0, q * 4UL);
+}
+
+char buf[128] __attribute__((aligned (32)));
+
+int
+main ()
+{
+ int i;
+ for (i = 0; i < 10; i++)
+foo (buf + 4, 1 + (i & 1));
+ for (i = 0; i < 128; i++)
+{
+ buf[i] = 'X';
+ asm volatile ("" : : : "memory");
+}
+ foo (buf + 32, 7);
+ for (i = 0; i < 128; i++)
+if (buf[i] != ((i < 32 || i >= 32 + 28) ? 'X' : 0))
+ __builtin_abort ();
+ return 0;
+}
Jakub
Re: [PATCH] Fix up expand_small_movmem_or_setmem (PR target/59003)
> Hi! > > As the testcase shows, for the memset (x, 0, y); snippet which handles > y from 16 to 31 inclusive for some tunings, we generate: > .L36: > movq$0, (%rdi) > movq$0, 8(%rdi) > movq$0, -8(%rsi,%rdi) Oops... > which is correct only for y from 16 to 24 inclusive, if y is 25 to 31, > we clear the first 16 bytes and last 8 bytes of the buffer, but would leave > 1 to 7 bytes untouched in between that. > With this patch we emit: > .L36: > movq$0, (%rdi) > movq$0, 8(%rdi) > movq$0, -16(%rsi,%rdi) > movq$0, -8(%rsi,%rdi) > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2014-01-21 Jakub Jelinek > > PR target/59003 > * config/i386/i386.c (expand_small_movmem_or_setmem): If mode is > smaller than size, perform several stores or loads and stores > at dst + count - size to store or copy all of size bytes, rather > than just last modesize bytes. > > * gcc.dg/tree-prof/pr59003.c: New test. Yes, this is OK. Thanks a lot for looking into that! This PR was on my TODO list for way too long (mostly because compilation farm machines are unasy to debug profiledbootstrap errors and I got new devel machine only last week). Honza
Re: [Patch] Fix regex `nosubs` correctly
On Tue, Jan 21, 2014 at 5:08 AM, Jonathan Wakely wrote: > What does Boost.Regex do? My conclusion is actually based on Boost.Regex's behavior. boost::basic_regex::mark_count() returns 1 with nosubs flag. Note that boost::basic_regex::mark_count() == std::basic_regex::mark_count() + 1, because std does not count the 0th capture (the whole regex) in. libc++'s mark_count returns 0 as well. -- Regards, Tim Shen
Re: [PATCH] Fix up expand_small_movmem_or_setmem (PR target/59003)
On Tue, Jan 21, 2014 at 08:08:19PM +0100, Jan Hubicka wrote: > Yes, this is OK. Thanks. BTW, I wonder if we got small expected_size_exp like in this case (6), if it is desirable to emit the large >= 32 size handling inline, if (say unless -minline-all-stringops) we couldn't just emit for that a library call. Of course only if expected_size_exp is sufficiently smaller than 32 that the larger sizes wouldn't occur too frequently (at least according to profile info). Jakub
patch to fix PR59858
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59858
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 206897.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59858
* gcc.target/arm/pr59858.c: New.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59858
* gcc.target/arm/pr59858.c: New.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 206844)
+++ lra-constraints.c (working copy)
@@ -688,9 +688,10 @@ operands_match_p (rtx x, rtx y, int y_ha
/* True if C is a non-empty register class that has too few registers
to be safely used as a reload target class. */
-#define SMALL_REGISTER_CLASS_P(C) \
- (reg_class_size [(C)] == 1 \
- || (reg_class_size [(C)] >= 1 && targetm.class_likely_spilled_p (C)))
+#define SMALL_REGISTER_CLASS_P(C) \
+ (ira_class_hard_regs_num [(C)] == 1 \
+ || (ira_class_hard_regs_num [(C)] >= 1 \
+ && targetm.class_likely_spilled_p (C)))
/* If REG is a reload pseudo, try to make its class satisfying CL. */
static void
@@ -2113,17 +2114,25 @@ process_alt_operands (int only_alternati
}
/* If the operand is dying, has a matching constraint,
and satisfies constraints of the matched operand
- which failed to satisfy the own constraints, we do
- not need to generate a reload insn for this
- operand. */
- if (!(this_alternative_matches >= 0
- && !curr_alt_win[this_alternative_matches]
- && REG_P (op)
- && find_regno_note (curr_insn, REG_DEAD, REGNO (op))
- && (hard_regno[nop] >= 0
- ? in_hard_reg_set_p (this_alternative_set,
- mode, hard_regno[nop])
- : in_class_p (op, this_alternative, NULL
+ which failed to satisfy the own constraints, probably
+ the reload for this operand will be gone. */
+ if (this_alternative_matches >= 0
+ && !curr_alt_win[this_alternative_matches]
+ && REG_P (op)
+ && find_regno_note (curr_insn, REG_DEAD, REGNO (op))
+ && (hard_regno[nop] >= 0
+ ? in_hard_reg_set_p (this_alternative_set,
+ mode, hard_regno[nop])
+ : in_class_p (op, this_alternative, NULL)))
+ {
+ if (lra_dump_file != NULL)
+ fprintf
+ (lra_dump_file,
+ "%d Dying matched operand reload: reject++\n",
+ nop);
+ reject++;
+ }
+ else
{
/* Strict_low_part requires to reload the register
not the sub-register. In this case we should
Index: testsuite/gcc.target/arm/pr59858.c
===
--- testsuite/gcc.target/arm/pr59858.c (revision 0)
+++ testsuite/gcc.target/arm/pr59858.c (working copy)
@@ -0,0 +1,162 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv5te -marm -mthumb-interwork -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -msoft-float -std=gnu99 -mlittle-endian -mthumb -fno-stack-protector -Os -g -feliminate-unused-debug-types -funit-at-a-time -fmerge-all-constants -fstrict-aliasing -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fPIC -w" } */
+
+typedef enum {
+ REG_ENOSYS = -1,
+} reg_errcode_t;
+typedef unsigned long int bitset_word_t;
+typedef bitset_word_t bitset_t[(256 / (sizeof (bitset_word_t) * 8))];
+typedef bitset_word_t *re_bitset_ptr_t;
+typedef const bitset_word_t *re_const_bitset_ptr_t;
+typedef struct {
+ int nelem;
+ int *elems;
+} re_node_set;
+typedef enum {
+ CHARACTER = 1,
+} re_token_type_t;
+typedef struct {
+ re_token_type_t type:8;
+ unsigned int word_char:1;
+} re_token_t;
+struct re_string_t {
+ const unsigned char *raw_mbs;
+ int raw_mbs_idx;
+ int cur_idx;
+ unsigned int tip_context;
+ re_const_bitset_ptr_t word_char;
+};
+typedef struct re_string_t re_string_t;
+typedef struct re_dfa_t re_dfa_t;
+struct re_dfastate_t {
+ re_node_set nodes;
+};
+typedef struct re_dfastate_t re_dfastate_t;
+typedef struct {
+ re_dfastate_t **array;
+} state_array_t;
+typedef struct {
+ state_array_t path;
+} re_sub_match_last_t;
+typedef struct {
+ int nlasts;
+ re_sub_match_last_t **lasts;
+} re_sub_match_top_t;
+typedef struct {
+ re_string_t input;
+ const re_dfa_t *dfa;
+ int nsub_tops;
+ re_sub_match_top_t **sub_tops;
+} re_match_context_t;
+struct re_dfa_t {
+ re_token_t *nodes;
+ re_bitset_ptr_t sb_char;
+ int mb_cur_max;
+ bitset_t word_char;
+} bracket_elem_t;
+static reg_errcode_t
+re_string_reconstruct (
+ re_string_t * pstr,
+ int idx,
+ int eflags
+)
+{
+ int offset = idx - pstr->raw_mbs_idx;
+ int c = pstr->raw_mbs[pstr->raw_mbs_idx + offset - 1];
+ pstr->tip_context = ((pstr->word_char[c] & ((bitset_word_t) 1)) ? : (c));
+}
+
+static void match_ctx_clean (
+ re_match_context_t *
+);
+static int check_matching (
+);
+static re_dfastate_t *transit_state (
+);
+static int build_trtable (
+);
+re_search_internal (int eflags
+)
+{
+ reg_errcode_t err;
+ int incr;
+ int
+ match_f
Re: patch to fix PR59858
On 01/21/2014 02:17 PM, Vladimir Makarov wrote: > The following patch fixes > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59858 > > The patch was successfully bootstrapped and tested on x86/x86-64. > > Committed as rev. 206897. > > 2014-01-21 Vladimir Makarov > > PR rtl-optimization/59858 > * gcc.target/arm/pr59858.c: New. > > > 2014-01-21 Vladimir Makarov > > PR rtl-optimization/59858 > * gcc.target/arm/pr59858.c: New. > > Sorry one changelog entry should be: 2014-01-21 Vladimir Makarov PR rtl-optimization/59858 * lra-constraints.c (SMALL_REGISTER_CLASS_P): Use ira_class_hard_regs_num. (process_alt_operands): Increase reject for dying matched operand.
Re: [PATCH] Fix up expand_small_movmem_or_setmem (PR target/59003)
> On Tue, Jan 21, 2014 at 08:08:19PM +0100, Jan Hubicka wrote: > > Yes, this is OK. > > Thanks. BTW, I wonder if we got small expected_size_exp like in this > case (6), if it is desirable to emit the large >= 32 size handling > inline, if (say unless -minline-all-stringops) we couldn't just emit for > that a library call. Of course only if expected_size_exp is sufficiently > smaller than 32 that the larger sizes wouldn't occur too frequently (at > least according to profile info). I think if we know we do not care about speed of the large block size case, we can simply inline rep;stosb since it is shorter than a library call. With -minline-stringop-dynamically we already do what you suggest and I have patch improving this a bit, just I was holding it until wrong code issues are solved, so it will wait for next stage1. I think in this case we also should use 16byte moves on AMD targets - it seems the logic is just overly strict about presence of vec_value; for 0 and 255 we can simply broadcast it ourselves. I will look into it. (probably not for other values, since loading constant from memory just to store it twice is probably not a win) Honza
Re: [Patch] Fix regex `nosubs` correctly
On 21/01/14 14:14 -0500, Tim Shen wrote: My conclusion is actually based on Boost.Regex's behavior. boost::basic_regex::mark_count() returns 1 with nosubs flag. Note that boost::basic_regex::mark_count() == std::basic_regex::mark_count() + 1, because std does not count the 0th capture (the whole regex) in. libc++'s mark_count returns 0 as well. OK, thanks for confirming that. In that case your patch is OK to commit. I'll raise a defect report against the standard as I don't think the specification of nosubs is clear. If that's what it means then it should be defined in terms of "marked sub-expressions" not just by stating the effect it has on match_results objects.
Re: [PATCH] libgcc: use linker script for libgcc_s.so on xtensa
On Mon, Jan 20, 2014 at 9:46 PM, Baruch Siach wrote: > Hi Sterling, > > On Mon, Jan 20, 2014 at 12:06:59PM -0800, Sterling Augustine wrote: >> On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach wrote: >> > The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement >> > __builtin_frame_address. This symbol is local/hidden in libgcc. This is >> > not a >> > problem when linking against static libgcc. But g++ defaults to >> > -shared-libgcc, thus breaking link against C++ shared libraries that are >> > using >> > __builtin_frame_address as follows: >> >> This is OK for mainline. > > Thanks. This is needed for the 4.7 and 4.8 branches as well. Checked in on all three branches. Cheers.
Re: [Patch] Fix regex `nosubs` correctly
On Tue, Jan 21, 2014 at 2:39 PM, Jonathan Wakely wrote: > OK, thanks for confirming that. In that case your patch is OK to > commit. Committed. > I'll raise a defect report against the standard as I don't think the > specification of nosubs is clear. If that's what it means then it > should be defined in terms of "marked sub-expressions" not just by > stating the effect it has on match_results objects. Thanks! -- Regards, Tim Shen
Re: [patch] fix libstdc++/56267 - local iterator requirements
On 21 January 2014 10:00, Jonathan Wakely wrote: > On 20 January 2014 21:11, François Dumont wrote: >> On 01/20/2014 04:53 PM, Jonathan Wakely wrote: >> >> With this new design couldn't we change the conditions that are used to >> decide when to cache the hash code. I haven't study it in detail but it >> looks like the default constructible constraint could be removed, no ? > > Ah yes, I forgot about that part, I'll update the __cache_default > definition. Thanks. Like so. Tested x86_64-linux, committed to trunk. 2014-01-21 Jonathan Wakely PR libstdc++/56267 * include/bits/hashtable.h (__cache_default): Do not depend on whether the hash function is DefaultConstructible or CopyAssignable. (_Hashtable): Adjust static assertions. * doc/xml/manual/containers.xml (containers.unordered.cache): Update. * testsuite/23_containers/unordered_set/instantiation_neg.cc: Adjust dg-error line number. * testsuite/23_containers/unordered_set/ not_default_constructible_hash_neg.cc: Remove. commit 0efc402079788226108bce180c478d4c85924fd4 Author: Jonathan Wakely Date: Tue Jan 21 18:20:24 2014 + PR libstdc++/56267 * include/bits/hashtable.h (__cache_default): Do not depend on whether the hash function is DefaultConstructible or CopyAssignable. (_Hashtable): Adjust static assertions. * doc/xml/manual/containers.xml (containers.unordered.cache): Update. * testsuite/23_containers/unordered_set/instantiation_neg.cc: Adjust dg-error line number. * testsuite/23_containers/unordered_set/ not_default_constructible_hash_neg.cc: Remove. diff --git a/libstdc++-v3/doc/xml/manual/containers.xml b/libstdc++-v3/doc/xml/manual/containers.xml index 9791953..653033d 100644 --- a/libstdc++-v3/doc/xml/manual/containers.xml +++ b/libstdc++-v3/doc/xml/manual/containers.xml @@ -420,7 +420,7 @@ the hash code every time it's needed can improve performance, but the additional memory overhead can also reduce performance, so whether an unordered associative container caches the hash code or not depends on - a number of factors. The caching policy for GCC 4.8 is described below. + the properties described below. The C++ standard requires that erase and swap @@ -432,23 +432,8 @@ or throw(). - Secondly, libstdc++ also needs the hash code in the implementation of - local_iterator and const_local_iterator in - order to know when the iterator has reached the end of the bucket. - This means that the local iterator types will embed a copy of the hash - function when possible. - Because the local iterator types must be DefaultConstructible and - CopyAssignable, if the hash function type does not model those concepts - then it cannot be embedded and so the hash code must be cached. - Note that a hash function might not be safe to use when - default-constructed (e.g if it a function pointer) so a hash - function that is contained in a local iterator won't be used until - the iterator is valid, so the hash function has been copied from a - correctly-initialized object. - - - If the hash function is non-throwing, DefaultConstructible and - CopyAssignable then libstdc++ doesn't need to cache the hash code for + If the hash function is non-throwing then libstdc++ doesn't need to + cache the hash code for correctness, but might still do so for performance if computing a hash code is an expensive operation, as it may be for arbitrarily long strings. diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h index e427c7f..4297c5f 100644 --- a/libstdc++-v3/include/bits/hashtable.h +++ b/libstdc++-v3/include/bits/hashtable.h @@ -42,10 +42,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION using __cache_default = __not_<__and_, - // Mandatory to make local_iterator default - // constructible and assignable. - is_default_constructible<_Hash>, - is_copy_assignable<_Hash>, // Mandatory to have erase not throwing. __detail::__is_noexcept_hash<_Tp, _Hash>>>; @@ -282,22 +278,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION "Functor used to map hash code to bucket index" " must be default constructible"); - // When hash codes are not cached local iterator inherits from - // __hash_code_base above to compute node bucket index so it has to be - // default constructible. - static_assert(__if_hash_not_cached< - is_default_constructible<__hash_code_base_access>>::value, - "Cache the hash code or make functors involved in hash code" - " and bucket index computation default constructibl
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, 21 Jan 2014, Marek Polacek wrote: --- gcc/libdecnumber/decNumberLocal.h.mp2014-01-21 18:34:32.235540589 +0100 +++ gcc/libdecnumber/decNumberLocal.h 2014-01-21 19:04:12.173243034 +0100 @@ -155,8 +155,10 @@ see the files COPYING3 and COPYING.RUNTI /* Store a uInt, etc., into bytes starting at a char* or uByte*.*/ /* Returns i, evaluated, for convenience; has to use uiwork because */ /* i may be an expression. */ - #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), uswork) - #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), uiwork) + #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), \ + (void)uswork) + #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), \ + (void)uiwork) This looks wrong to me. The comment before says that those macros "return" uiwork, so you can't cast it to void in the macro. Options: 1) cast to void in the users of the macro: (void) UBFROMUS(acc+4, 0); 2) Make the macros not return (since none of the users use the return value), i.e. remove ", uiwork" at the end and update the comment before. (you may need to cast the return of memcpy to void, which makes more sense) -- Marc Glisse
Re: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
Hi Matthew, Just wanted to add a couple of MIPS-specific things on top of what Joseph said: Matthew Fortune writes: > The MSA patch as submitted is another variation of O32 ABI which could > be described as O32+FP64+MSA(+nan2008) and would be link incompatible > with both O32 and O32+FP64(+/-nan2008). The same of course applies to > N32/N64 being link incompatible with N32/N64+FP64. This may make it > difficult to have a small part of an application optimised with MSA but > the rest of the code ignorant of MSA, in your experience do you think > that will be an issue? FWIW, n32/n64 is always fp64 -- we don't support an fp32 version. And as you imply, o32+fp64 is already an established ABI so I think we have to support the current form alongside any new one. I agree with Joseph that it'd be better to realign the stack dynamically instead. This is what x86 does, so it's well tested within gcc. Also, I think there was a possibility of adding a 256-bit form of MSA in future, is that right? So if we added extra static alignments, would we need a separate ABI for 256-bit MSA too? > We (MIPS) have several discussions ongoing regarding ABIs on a variety > of mailing lists so I'm trying to collect as much input as possible to > inform future plans. > > One part of the patch that I don't believe you commented on is the > change of stack alignment for both existing O32+FP64 and new > O32+FP64+MSA. Did this seem OK? No, sorry, not sure why I didn't include that. Thanks, Richard
[jit] Add gcc_jit_function_add_comment
Committed to dmalcolm/jit branch:
Add gcc_jit_function_add_comment, a way to add a no-op textual comment to
the internal representation of the code.
It will be optimized away, but will be visible in some dumps
and thus may be of use when debugging how client code's internal
representation gets converted to the libgccjit IR.
Internally, it's implemented by adding a dummy label to the IR, where the
name of the label is the text of the comment, wrapped in C-style comment
delimiters.
Currently this is directly visible in the tree and gimple dumps, and
seems to survive all the way through to the end of RTL, in the form
of NOTE_INSN_DELETED_LABEL. It doesn't make it into the final assembler
output, though.
---
gcc/jit/ChangeLog.jit | 8
gcc/jit/internal-api.c | 21 +
gcc/jit/internal-api.h | 4
gcc/jit/libgccjit.c | 11 +++
gcc/jit/libgccjit.h | 13 +
gcc/jit/libgccjit.map | 1 +
gcc/testsuite/ChangeLog.jit | 5 +
gcc/testsuite/jit.dg/test-hello-world.c | 5 +
8 files changed, 68 insertions(+)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 30664be..c899c9a 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,11 @@
+2014-01-21 David Malcolm
+
+ * internal-api.c (gcc::jit::function::add_comment): New.
+ * internal-api.h (gcc::jit::function::add_comment): New.
+ * libgccjit.c (gcc_jit_function_add_comment): New.
+ * libgccjit.h (gcc_jit_function_add_comment): New.
+ * libgccjit.map: Add gcc_jit_function_add_comment.
+
2013-10-24 David Malcolm
* internal-api.c (gcc::jit::function::add_eval): Handle non-NULL
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index b21aaa6..a92c797 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -923,6 +923,27 @@ add_assignment (location *loc,
void
gcc::jit::function::
+add_comment (location *loc,
+const char *text)
+{
+ gcc_assert (m_kind != GCC_JIT_FUNCTION_IMPORTED);
+
+ /* Wrap the text in C-style comment delimiters. */
+ size_t sz =
+(3 /* opening delim */
+ + strlen (text)
+ + 3 /* closing delim */
+ + 1 /* terminator */);
+ char *wrapped = (char *)ggc_internal_alloc_stat (sz);
+ snprintf (wrapped, sz, "/* %s */", text);
+
+ /* For now we simply implement this by adding a dummy label with a name
+ containing the given text. */
+ add_label (loc, wrapped);
+}
+
+void
+gcc::jit::function::
add_conditional (location *loc,
rvalue *boolval,
label *on_true,
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index 01f0bb3..1ec2ea1 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -319,6 +319,10 @@ public:
rvalue *rvalue);
void
+ add_comment (location *loc,
+ const char *text);
+
+ void
add_conditional (location *loc,
rvalue *boolval,
label *on_true,
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 3222144..d094def 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -639,6 +639,17 @@ gcc_jit_function_add_conditional (gcc_jit_function *func,
}
void
+gcc_jit_function_add_comment (gcc_jit_function *func,
+ gcc_jit_location *loc,
+ const char *text)
+{
+ RETURN_IF_NOT_FUNC_DEFINITION (func);
+ RETURN_IF_FAIL (text, NULL, "NULL text");
+
+ func->add_comment (loc, text);
+}
+
+void
gcc_jit_function_add_jump (gcc_jit_function *func,
gcc_jit_location *loc,
gcc_jit_label *target)
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 0712533..8a6682b 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -668,6 +668,19 @@ gcc_jit_function_add_assignment_op (gcc_jit_function *func,
enum gcc_jit_binary_op op,
gcc_jit_rvalue *rvalue);
+/* Add a no-op textual comment to the internal representation of the
+ code. It will be optimized away, but will be visible in the dumps
+ seen via
+ GCC_JIT_BOOL_OPTION_DUMP_INITIAL_TREE
+ and
+ GCC_JIT_BOOL_OPTION_DUMP_INITIAL_GIMPLE,
+ and thus may be of use when debugging how your project's internal
+ representation gets converted to the libgccjit IR. */
+extern void
+gcc_jit_function_add_comment (gcc_jit_function *func,
+ gcc_jit_location *loc,
+ const char *text);
+
/* Add evaluation of an rvalue, branching on the result to the
appropriate label.
diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
index aaa2112..bcb4411 100644
--- a/gcc/jit/libgccjit.map
+++ b/gcc/jit/libgccjit.map
@@ -30,6 +30,7 @@
gcc_jit_context_zero;
gcc_jit_function_add_assignment;
Re: Resolve pr44194-1.c failure by refining scan-rtl-dump-not pattern
Eric Botcazou writes: >> I have made the adjustment and test it. Please check the new attachment. > > Thanks, applied on the mainline as obvious. It looks like the committed version removed the space after "insn". Was that intentional? It now triggers on MIPS because of the frame-related (insn/f) prologue instruction that stores the link register. The posted version works for me FWIW. And I guess this shows that it'd be worth having a comment saying _why_ the space is needed. :-) Thanks, Richard
[MIPS, committed] Adding missing register move costs for M16_REGS
This patch fixes a stupid oversight in:
2008-10-24 Richard Sandiford
* config/mips/mips.c (mips_canonicalize_move_class): New function.
(mips_move_to_gpr_cost): Likewise.
(mips_move_from_gpr_cost): Likewise.
(mips_register_move_cost): Make more fine-grained.
The idea was to handle the various subclasses and union classes correctly,
but I missed out the case for M16_REGS. This meant that some MIPS16 moves
were wrongly getting a cost of 0 instead of the correct cost of 2.
That in turn caused a segfault when dividing by a register cost in
gcc.dg/pr37156.c.
I tried to see what effect this patch had on code size for -Os -mips16,
but as usual it was a case of some better, some worse. The overall
change was of the order of 0.01%. As a point of comparison I tried
disabling Steve's patch to fix the $t registers and as expected the
results were more consistently worse.
Anyway, it's wrong to return 0 as a move cost for non-union classes,
so we need something like this whatever happens. It probably doesn't
make much sense to tune the costs further with reload instead of LRA.
Tested on mips64-linux-gnu and applied.
Thanks,
Richard
gcc/
* config/mips/mips.c (mips_move_to_gpr_cost): Add M16_REGS case.
(mips_move_from_gpr_cost): Likewise.
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c 2014-01-21 20:38:01.864324981 +
+++ gcc/config/mips/mips.c 2014-01-21 20:38:53.734788910 +
@@ -11883,6 +11883,7 @@ mips_move_to_gpr_cost (enum machine_mode
{
switch (from)
{
+case M16_REGS:
case GENERAL_REGS:
/* A MIPS16 MOVE instruction, or a non-MIPS16 MOVE macro. */
return 2;
@@ -11919,6 +11920,7 @@ mips_move_from_gpr_cost (enum machine_mo
{
switch (to)
{
+case M16_REGS:
case GENERAL_REGS:
/* A MIPS16 MOVE instruction, or a non-MIPS16 MOVE macro. */
return 2;
Re: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
On Tue, 21 Jan 2014, Richard Sandiford wrote: > And as you imply, o32+fp64 is already an established ABI so I think we > have to support the current form alongside any new one. I agree with > Joseph that it'd be better to realign the stack dynamically instead. > This is what x86 does, so it's well tested within gcc. With glibc, o32+fp64 is not established - the glibc patch submitted in November needs more work as I noted in my review, likely to include dynamic linker names distinct from those used for o32+fp32. So it would be possible to declare that only a new form is supported with glibc (more generally, with the Linux kernel, given the lack of current kernel support for o32+fp64 stated in the glibc discussion), with appropriate configure checks preventing building glibc with an old-ABI o32+fp64 compiler (and ideally a #error in some glibc header disallowing building programs with an old-ABI o32+fp64 compiler). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix use-after-return-1.c
On Jan 21, 2014, at 5:51 AM, Maxim Ostapenko wrote: > This patch fixes c-c++-common/asan/use-after-return-1.c not to fail on darwin > target (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897). > > Ok to commit? Ok.
patch to fix PR59896
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59896
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev 206908.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59896
* lra-constraints.c (process_alt_operands): Check unused note for
matched operands of insn with no output reloads.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59896
* gcc.target/arm/pr59896.c: New.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 206897)
+++ lra-constraints.c (working copy)
@@ -2199,7 +2199,13 @@ process_alt_operands (int only_alternati
|| (curr_static_id->operand[nop].type != OP_OUT
&& no_input_reloads_p && ! const_to_mem)
|| (this_alternative_matches >= 0
- && (no_input_reloads_p || no_output_reloads_p)))
+ && (no_input_reloads_p
+ || (no_output_reloads_p
+ && (curr_static_id->operand
+ [this_alternative_matches].type != OP_IN)
+ && ! find_reg_note (curr_insn, REG_UNUSED,
+ no_subreg_reg_operand
+ [this_alternative_matches])
{
if (lra_dump_file != NULL)
fprintf
Index: testsuite/gcc.target/arm/pr59896.c
===
--- testsuite/gcc.target/arm/pr59896.c (revision 0)
+++ testsuite/gcc.target/arm/pr59896.c (working copy)
@@ -0,0 +1,1374 @@
+/* { dg-do compile } */
+/* { dg-options "-mthumb -O2" } */
+
+typedef unsigned int size_t;
+typedef unsigned int wchar_t;
+typedef int ptrdiff_t;
+typedef signed char __int8_t ;
+typedef unsigned char __uint8_t ;
+typedef signed short __int16_t;
+typedef unsigned short __uint16_t;
+typedef __int16_t __int_least16_t;
+typedef __uint16_t __uint_least16_t;
+typedef signed int __int32_t;
+typedef unsigned int __uint32_t;
+typedef __int32_t __int_least32_t;
+typedef __uint32_t __uint_least32_t;
+typedef signed long long __int64_t;
+typedef unsigned long long __uint64_t;
+typedef int _LOCK_T;
+typedef int _LOCK_RECURSIVE_T;
+typedef long _off_t;
+typedef short __dev_t;
+typedef unsigned short __uid_t;
+typedef unsigned short __gid_t;
+__extension__ typedef long long _off64_t;
+typedef long _fpos_t;
+typedef signed int _ssize_t;
+typedef unsigned int wint_t;
+typedef struct
+{
+ int __count;
+ union
+ {
+wint_t __wch;
+unsigned char __wchb[4];
+ } __value;
+} _mbstate_t;
+typedef _LOCK_RECURSIVE_T _flock_t;
+typedef void *_iconv_t;
+typedef unsigned long __ULong;
+struct _reent;
+struct _Bigint
+{
+ struct _Bigint *_next;
+ int _k, _maxwds, _sign, _wds;
+ __ULong _x[1];
+};
+struct __tm
+{
+ int __tm_sec;
+ int __tm_min;
+ int __tm_hour;
+ int __tm_mday;
+ int __tm_mon;
+ int __tm_year;
+ int __tm_wday;
+ int __tm_yday;
+ int __tm_isdst;
+};
+struct _on_exit_args {
+ void * _fnargs[32];
+ void * _dso_handle[32];
+ __ULong _fntypes;
+ __ULong _is_cxa;
+};
+struct _atexit {
+ struct _atexit *_next;
+ int _ind;
+ void (*_fns[32])(void);
+struct _on_exit_args _on_exit_args;
+};
+struct __sbuf {
+ unsigned char *_base;
+ int _size;
+};
+struct __sFILE {
+ unsigned char *_p;
+ int _r;
+ int _w;
+ short _flags;
+ short _file;
+ struct __sbuf _bf;
+ int _lbfsize;
+ void * _cookie;
+ int (* _read) (struct _reent *, void *, char *, int)
+ ;
+ int (* _write) (struct _reent *, void *, const char *, int)
+ ;
+ _fpos_t (* _seek) (struct _reent *, void *, _fpos_t, int);
+ int (* _close) (struct _reent *, void *);
+ struct __sbuf _ub;
+ unsigned char *_up;
+ int _ur;
+ unsigned char _ubuf[3];
+ unsigned char _nbuf[1];
+ struct __sbuf _lb;
+ int _blksize;
+ _off_t _offset;
+ struct _reent *_data;
+ _flock_t _lock;
+ _mbstate_t _mbstate;
+ int _flags2;
+};
+typedef struct __sFILE __FILE;
+struct _glue
+{
+ struct _glue *_next;
+ int _niobs;
+ __FILE *_iobs;
+};
+struct _rand48 {
+ unsigned short _seed[3];
+ unsigned short _mult[3];
+ unsigned short _add;
+};
+struct _reent
+{
+ int _errno;
+ __FILE *_stdin, *_stdout, *_stderr;
+ int _inc;
+ char _emergency[25];
+ int _current_category;
+ const char *_current_locale;
+ int __sdidinit;
+ void (* __cleanup) (struct _reent *);
+ struct _Bigint *_result;
+ int _result_k;
+ struct _Bigint *_p5s;
+ struct _Bigint **_freelist;
+ int _cvtlen;
+ char *_cvtbuf;
+ union
+{
+ struct
+{
+ unsigned int _unused_rand;
+ char * _strtok_last;
+ char _asctime_buf[26];
+ struct __tm _localtime_buf;
+ int _gamma_signgam;
+ __extension__ unsigned long long _rand_next;
+ struct _rand48 _r48;
+ _mbstate_t _mblen_state;
+ _mbstate_t _mbtowc_state;
+ _mbstate_t _wctomb_state;
+ char _l64a_buf[8];
+ char _signal_buf[24];
+ int _getdate_err;
+ _mbstate_t _mbrlen_state;
+
[google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
Hi,
Currently, tree unrolling pass(cunroll) does not allow any code
size growth in O2 mode. Code size growth is permitted only if O3 or
funroll-loops/fpeel-loops is used. I have created a patch to allow
partial code size increase in O2 mode. With funroll-loops the maximum
allowed code growth is 400 unrolled insns. I have set it to 200
unrolled insns in O2 mode. This patch improves an image processing
benchmark by 20%. It improves most benchmarks by 1-2%. The code size
increase is <1% for all the benchmarks except the image processing
benchmark which increases by 6% (perf improves by 20%).
I am working on getting this patch reviewed for trunk. Here is
the disussion on this:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have
incorporated the comments on making the patch simpler. I will
follow-up on that patch to trunk by also getting data on limiting
complete peeling with O2.
Is this ok for the google branch?
Thanks
Sri
Index: opts.c
===
--- opts.c (revision 206638)
+++ opts.c (working copy)
@@ -855,6 +855,19 @@ finish_options (struct gcc_options *opts, struct g
0, opts->x_param_values, opts_set->x_param_values);
}
+ /* Set PARAM_MAX_COMPLETELY_PEELED_INSNS to half its original value during
+ -O2 when -funroll-loops and -fpeel-loops are not set. */
+ if (optimize == 2 && !opts->x_flag_unroll_loops && !opts->x_flag_peel_loops
+ && !opts->x_flag_unroll_all_loops)
+
+{
+ unsigned HOST_WIDE_INT max_completely_peeled_insns
+ = (PARAM_VALUE (PARAM_MAX_COMPLETELY_PEELED_INSNS) / 2);
+ maybe_set_param_value (PARAM_MAX_COMPLETELY_PEELED_INSNS,
+max_completely_peeled_insns,
+opts->x_param_values, opts_set->x_param_values);
+}
+
/* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion
is disabled. */
if ((!opts->x_flag_tree_loop_vectorize && !opts->x_flag_tree_slp_vectorize)
Index: tree-ssa-loop.c
===
--- tree-ssa-loop.c (revision 206638)
+++ tree-ssa-loop.c (working copy)
@@ -467,7 +467,7 @@ tree_complete_unroll (void)
return tree_unroll_loops_completely (flag_unroll_loops
|| flag_peel_loops
- || optimize >= 3, true);
+ || optimize >= 2, true);
}
static bool
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 09:18:17PM +0100, Marc Glisse wrote: > On Tue, 21 Jan 2014, Marek Polacek wrote: > > >--- gcc/libdecnumber/decNumberLocal.h.mp 2014-01-21 18:34:32.235540589 > >+0100 > >+++ gcc/libdecnumber/decNumberLocal.h2014-01-21 19:04:12.173243034 > >+0100 > >@@ -155,8 +155,10 @@ see the files COPYING3 and COPYING.RUNTI > > /* Store a uInt, etc., into bytes starting at a char* or uByte*.*/ > > /* Returns i, evaluated, for convenience; has to use uiwork because */ > > /* i may be an expression. */ > >- #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), > >uswork) > >- #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), > >uiwork) > >+ #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), \ > >+ (void)uswork) > >+ #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), \ > >+ (void)uiwork) > > This looks wrong to me. The comment before says that those macros > "return" uiwork, so you can't cast it to void in the macro. Options: > > 1) cast to void in the users of the macro: > (void) UBFROMUS(acc+4, 0); > > 2) Make the macros not return (since none of the users use the > return value), i.e. remove ", uiwork" at the end and update the > comment before. (you may need to cast the return of memcpy to void, > which makes more sense) I went with 2). Still it looks kind of weird, but I don't care enough as long as it bootstraps ;). I'll post a patch once the regtesting finishes. Thanks. Marek
Re: Fix bootstrap with -mno-accumulate-outgoing-args
On 01/17/14 14:32, Jan Hubicka wrote: * combine-stack-adj.c (combine_stack_adjustments_for_block): Remove ARG_SIZE note when adjustment was eliminated. Ping... This patch prevents me from switching the accumulate-args default for generic and I am waiting for that witht he inliner tunning, so there is quite a dependency chain. This is fine. Can you add a testcase for this? jeff
Merge from trunk to gccgo branch
I merged revision 206906 from trunk to the gccgo branch. Ian
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 07:50:13PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2014 at 07:38:10PM +0100, Marek Polacek wrote:
> > --- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
> > +++ gcc/gcc/c/c-typeck.c2014-01-21 18:10:53.900279750 +0100
> > @@ -4757,6 +4757,18 @@ build_compound_expr (location_t loc, tre
> >expr2 = TREE_OPERAND (expr2, 0);
> > }
> >
> > + if (TREE_CODE (expr1) == COMPOUND_EXPR
> > + && warn_unused_value)
> > +{
> > + tree r = expr1;
> > + while (TREE_CODE (r) == COMPOUND_EXPR)
> > +r = TREE_OPERAND (r, 1);
> > + if (!TREE_SIDE_EFFECTS (r)
> > + && !VOID_TYPE_P (TREE_TYPE (r))
> > + && !CONVERT_EXPR_P (r))
> > + warning_at (loc, OPT_Wunused_value,
> > + "right-hand operand of comma expression has no effect");
> > +}
> >if (!TREE_SIDE_EFFECTS (expr1))
> > {
> >/* The left-hand operand of a comma expression is like an expression
>
> Won't this warn twice if !TREE_SIDE_EFFECTS (expr1) and expr1 is a
> COMPOUND_EXPR? I would be expecting this whole if as else if below the
> !TREE_SIDE_EFFECTS case. I mean, in emit_side_effect_warnings you do it
> the same way, and if nothing in the expr1 COMPOUND_EXPR has any
> !side-effects, then it is ok to complain about the expr1 as whole, no
> need to complain particularly about the rhs of it.
Ooops, for some reason I moved the whole if above. I've changed it
so it's the same as in the emit_side_effect_warnings now, meaning that for
1, 1, 1; we emit what GCC 4.8 emits.
> Also, shouldn't you use EXPR_LOCATION of the COMPOUND_EXPR r is rhs of
> in the end? I.e. do something like:
> location_t cloc = loc;
> while (TREE_CODE (r) == COMPOUND_EXPR)
> {
> if (EXPR_HAS_LOCATION (r)) cloc = EXPR_LOCATION (r);
> r = TREE_OPERAND (r, 1);
> }
> and use cloc in warning_at.
Yes, this produces better locus, so thanks for the hint.
I made another small change: in the second hunk, in
emit_side_effect_warnings, I got rid of the while, since it seems to
me we never get COMPOUND_EXPR in TREE_OPERAND (r, 1).
Furthermore, I incorporated a change into decNumberLocal.h, which Marc
suggested.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-01-21 Marek Polacek
PR c/59871
c/
* c-typeck.c (build_compound_expr): Warn even for right-hand operand
of comma expression.
(emit_side_effect_warnings): Likewise.
libdecnumber/
* decNumberLocal.h (UBFROMUS, UBFROMUI): Remove last argument.
testsuite/
* gcc.dg/20020220-2.c: Adjust dg-warning message.
* gcc.dg/pr59871.c: New test.
--- gcc/libdecnumber/decNumberLocal.h.mp2014-01-21 18:34:32.235540589
+0100
+++ gcc/libdecnumber/decNumberLocal.h 2014-01-21 22:04:34.331223218 +0100
@@ -153,10 +153,9 @@ see the files COPYING3 and COPYING.RUNTI
#define UBTOUI(b) (memcpy((void *)&uiwork, b, 4), uiwork)
/* Store a uInt, etc., into bytes starting at a char* or uByte*.*/
- /* Returns i, evaluated, for convenience; has to use uiwork because */
- /* i may be an expression. */
- #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2), uswork)
- #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4), uiwork)
+ /* Has to use uiwork because i may be an expression. */
+ #define UBFROMUS(b, i) (uswork=(i), memcpy(b, (void *)&uswork, 2))
+ #define UBFROMUI(b, i) (uiwork=(i), memcpy(b, (void *)&uiwork, 4))
/* X10 and X100 -- multiply integer i by 10 or 100 */
/* [shifts are usually faster than multiply; could be conditional] */
--- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
+++ gcc/gcc/c/c-typeck.c2014-01-21 22:06:32.349778039 +0100
@@ -4776,6 +4776,23 @@ build_compound_expr (location_t loc, tre
"left-hand operand of comma expression has no effect");
}
}
+ else if (TREE_CODE (expr1) == COMPOUND_EXPR
+ && warn_unused_value)
+{
+ tree r = expr1;
+ location_t cloc = loc;
+ while (TREE_CODE (r) == COMPOUND_EXPR)
+{
+ if (EXPR_HAS_LOCATION (r))
+ cloc = EXPR_LOCATION (r);
+ r = TREE_OPERAND (r, 1);
+ }
+ if (!TREE_SIDE_EFFECTS (r)
+ && !VOID_TYPE_P (TREE_TYPE (r))
+ && !CONVERT_EXPR_P (r))
+ warning_at (cloc, OPT_Wunused_value,
+ "right-hand operand of comma expression has no effect");
+}
/* With -Wunused, we should also warn if the left-hand operand does have
side-effects, but computes a value which is not used. For example, in
@@ -9641,6 +9658,16 @@ emit_side_effect_warnings (location_t lo
if (!VOID_TYPE_P (TREE_TYPE (expr)) && !TREE_NO_WARNING (expr))
warning_at (loc, OPT_Wunused_value, "statement with no effect");
}
+ else if (TREE_CODE (expr) == COMPOUND_EXPR)
+{
+ tree r = TREE_OPERAND (ex
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote: > I made another small change: in the second hunk, in > emit_side_effect_warnings, I got rid of the while, since it seems to > me we never get COMPOUND_EXPR in TREE_OPERAND (r, 1). For bar (), 1, 2, 3, 4, 5, 6, 7, 8; sure, but what about (1, (2, (3, (4, (5, (6, (bar (), 7))); ? Jakub
PR59723: fix LTO + fortran namelist ICEs
Hi folks.
The problem here is that while streaming the DECL_NAME with
stream_read_tree() and consequently lto_output_tree(), we trigger an ICE
because we are recursing on the DFS walk:
else
{
/* This is the first time we see EXPR, write all reachable
trees to OB. */
static bool in_dfs_walk;
/* Protect against recursion which means disconnect between
what tree edges we walk in the DFS walk and what edges
we stream out. */
gcc_assert (!in_dfs_walk);
In the namelist fortran testcases, this is the first time we see the
DECL_NAMEs, so we ICE. I fixed this by outputting the DECL_NAME's
string with streamer_write_string() instead.
[I honestly wondered why we don't stream the entire NAMELIST_DECL the
same way we stream IMPORTED_DECL, all in one go, instead of piecemeal
like the present code does. But LTO is this complicated black box in my
head that I try not to think about too much...the current patch touches
as little as possible.]
This change alone fixes the problems in the PR, but I also found another
ICE now that streaming actually works: dwarf. It turns out, that the
way the CONSTRUCTOR elements in the NAMELIST_DECL are streamed, a
PARM_DECL that has been previously seen (in the function's
DECL_ARGUMENTS) will be streamed with different reference magic (or
whatever streamed references or ids are called in LTO speak). So when
we read the CONSTRUCTOR elements in the LTO read phase, we end up with
different pointers for a PARM_DECL in the constructor for the seemingly
same PARM_DECL in the function's arguments (DECL_ARGUMENTS).
I don't understand LTO very well, but I do see that using
stream_read_tree (lto_output_tree) caches the entries, so it seems like
a good fit to avoid writing two distinct items for the same PARM_DECL.
And since the constructor elements have been previously seen, we won't
hit the aforementioned DFS recursion ICE.
It'd be great if the LTO gods could illuminate this abyss (that's you
Mr. Biener ;-)), but the attached patch fixes all the LTO problems
exhibited by:
make check-fortran RUNTESTFLAGS="--target_board=unix'{-flto}'
dg.exp=*namelist*"
As an aside, we really should test some subset of the LTO tests while
testing Fortran, or this oversight will surely repeat itself on any
changes to the Fortran streamer bits.
Does this help? OK?
Aldy
commit a916bfe9fec9b62971cea769ae58d4b3467e08bd
Author: Aldy Hernandez
Date: Fri Jan 17 08:01:44 2014 -0800
* lto-streamer-in.c (lto_input_tree_ref): Use streamer_read_string
instead of stream_read_tree. Read in constructos with
stream_read_tree.
* lto-streamer-out.c (lto_output_tree_ref): Do not recurse on DFS
walk. Output constructors correctly.
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index df32a6b..9eec472 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -256,12 +256,12 @@ lto_input_tree_ref (struct lto_input_block *ib, struct
data_in *data_in,
result = make_node (NAMELIST_DECL);
TREE_TYPE (result) = void_type_node;
- DECL_NAME (result) = stream_read_tree (ib, data_in);
+ DECL_NAME (result) = get_identifier (streamer_read_string (data_in,
+ ib));
n = streamer_read_uhwi (ib);
for (i = 0; i < n; i++)
{
- ix_u = streamer_read_uhwi (ib);
- tmp = lto_file_decl_data_get_var_decl (data_in->file_data, ix_u);
+ tmp = stream_read_tree (ib, data_in);
gcc_assert (tmp != NULL_TREE);
CONSTRUCTOR_APPEND_ELT (nml_decls, NULL_TREE, tmp);
}
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 5d6aed5..dc48dd4 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -260,12 +260,13 @@ lto_output_tree_ref (struct output_block *ob, tree expr)
tree value, tmp;
streamer_write_record_start (ob, LTO_namelist_decl_ref);
- stream_write_tree (ob, DECL_NAME (expr), true);
+ streamer_write_string (ob, ob->main_stream,
+ IDENTIFIER_POINTER (DECL_NAME (expr)), true);
tmp = NAMELIST_DECL_ASSOCIATED_DECL (expr);
gcc_assert (tmp != NULL_TREE);
streamer_write_uhwi (ob, CONSTRUCTOR_ELTS (tmp)->length());
FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (tmp), i, value)
- lto_output_var_decl_index (ob->decl_state, ob->main_stream, value);
+ stream_write_tree (ob, value, true);
break;
}
Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
I think it might be better to introduce a new parameter for max peel insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or MAX_DEFAULT_...), and use the same logic in your patch to override the MAX_COMPLETELY_PEELED_INSN parameter at O2). By so doing, we don't need to have a hard coded factor of 2. In the longer run, we really need better cost/benefit analysis, but that is independent. David On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam wrote: > Hi, > > Currently, tree unrolling pass(cunroll) does not allow any code > size growth in O2 mode. Code size growth is permitted only if O3 or > funroll-loops/fpeel-loops is used. I have created a patch to allow > partial code size increase in O2 mode. With funroll-loops the maximum > allowed code growth is 400 unrolled insns. I have set it to 200 > unrolled insns in O2 mode. This patch improves an image processing > benchmark by 20%. It improves most benchmarks by 1-2%. The code size > increase is <1% for all the benchmarks except the image processing > benchmark which increases by 6% (perf improves by 20%). > > I am working on getting this patch reviewed for trunk. Here is > the disussion on this: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have > incorporated the comments on making the patch simpler. I will > follow-up on that patch to trunk by also getting data on limiting > complete peeling with O2. > > Is this ok for the google branch? > > Thanks > Sri
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 11:34:42PM +0100, Jakub Jelinek wrote: > On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote: > > I made another small change: in the second hunk, in > > emit_side_effect_warnings, I got rid of the while, since it seems to > > me we never get COMPOUND_EXPR in TREE_OPERAND (r, 1). > > For bar (), 1, 2, 3, 4, 5, 6, 7, 8; sure, but what about > (1, (2, (3, (4, (5, (6, (bar (), 7))); ? For that `expr' that emit_side_effect_warnings gets is: unit size align 32 symtab 0 alias set -1 canonical type 0x7ffe27144690 precision 32 min max pointer_to_this > side-effects arg 0 side-effects fn constant arg 0 uu.c:19:32> uu.c:19:32> arg 1 constant 7> uu.c:19:5> so we should be fine even in that case. Marek
Re: [C PATCH] Warn about unused RHS of COMPOUND_EXPR (PR c/59871)
On Tue, Jan 21, 2014 at 11:54:03PM +0100, Marek Polacek wrote: > On Tue, Jan 21, 2014 at 11:34:42PM +0100, Jakub Jelinek wrote: > > On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote: > > > I made another small change: in the second hunk, in > > > emit_side_effect_warnings, I got rid of the while, since it seems to > > > me we never get COMPOUND_EXPR in TREE_OPERAND (r, 1). > > > > For bar (), 1, 2, 3, 4, 5, 6, 7, 8; sure, but what about > > (1, (2, (3, (4, (5, (6, (bar (), 7))); ? > > For that `expr' that emit_side_effect_warnings gets is: > type size > unit size > align 32 symtab 0 alias set -1 canonical type 0x7ffe27144690 > precision 32 min max 0x7ffe27146380 2147483647> > pointer_to_this > > side-effects > arg 0 > side-effects > fn > constant arg 0 > uu.c:19:32> > uu.c:19:32> > arg 1 > constant 7> > uu.c:19:5> > so we should be fine even in that case. And for (bar (), (bar (), (bar (), (bar (), (bar (), (bar (), (bar (), 7))); ? On the other side, there is warn_if_unused_value, which specifically has: /* Let people do `(foo (), 0)' without a warning. */ if (TREE_CONSTANT (TREE_OPERAND (exp, 1))) return false; so perhaps it is intentional that we don't warn about this? That stuff dates all the way back to r759. Though I wonder why it would be desirable to warn about this for C++ and not for C. Jakub
fix inconsistent install paths between gccgo and go tool
Hi,
This patch for the 4.8 branch fixes an inconsistency between gccgo's
libgo and the go tool over where libraries installed with "go install
-compiler gccgo" end up. Even if it's not strictly required, it makes
sense to me that as gccgo implements go 1.1 it should match the go tool
from that particular version of the go distribution (and also newer
ones!).
Cheers,
mwh
diff --git a/libgo/go/go/build/build.go b/libgo/go/go/build/build.go
index cc89afb..59ddcef 100644
--- a/libgo/go/go/build/build.go
+++ b/libgo/go/go/build/build.go
@@ -429,7 +429,7 @@ func (ctxt *Context) Import(path string, srcDir string, mode ImportMode) (*Packa
switch ctxt.Compiler {
case "gccgo":
dir, elem := pathpkg.Split(p.ImportPath)
- pkga = "pkg/gccgo/" + dir + "lib" + elem + ".a"
+ pkga = "pkg/gccgo_" + ctxt.GOOS + "_" + ctxt.GOARCH + "/" + dir + "lib" + elem + ".a"
case "gc":
suffix := ""
if ctxt.InstallSuffix != "" {
Re: Resolve pr44194-1.c failure by refining scan-rtl-dump-not pattern
> It looks like the committed version removed the space after "insn". > Was that intentional? It now triggers on MIPS because of the frame-related > (insn/f) prologue instruction that stores the link register. The posted > version works for me FWIW. I found out that it didn't fail with the space on x86 (hence false negative) because of the TI marker added by some RTL pass. Feel free to adjust back. -- Eric Botcazou
Re: Fix bootstrap with -mno-accumulate-outgoing-args
> On 01/17/14 14:32, Jan Hubicka wrote: > >>* combine-stack-adj.c (combine_stack_adjustments_for_block): Remove > >>ARG_SIZE note when adjustment was eliminated. > > > >Ping... This patch prevents me from switching the accumulate-args default > >for generic and I am waiting for that witht he inliner tunning, so there is > >quite a dependency chain. > This is fine. > > Can you add a testcase for this? It occurs during bootstrap compiling go, so I think we should have this covered. I will try to construct some artificial testcase in C, but it seems a bit tricky. Thank you! Jan > > jeff
Re: fix inconsistent install paths between gccgo and go tool
On Tue, Jan 21, 2014 at 3:29 PM, Michael Hudson-Doyle wrote: > > This patch for the 4.8 branch fixes an inconsistency between gccgo's > libgo and the go tool over where libraries installed with "go install > -compiler gccgo" end up. Even if it's not strictly required, it makes > sense to me that as gccgo implements go 1.1 it should match the go tool > from that particular version of the go distribution (and also newer > ones!). This is OK for 4.8 branch. Thanks. Ian
Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li wrote:
> I think it might be better to introduce a new parameter for max peel
> insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or
> MAX_DEFAULT_...), and use the same logic in your patch to override the
> MAX_COMPLETELY_PEELED_INSN parameter at O2).
>
> By so doing, we don't need to have a hard coded factor of 2.
Patch attached with that change.
Sri
>
> In the longer run, we really need better cost/benefit analysis, but
> that is independent.
>
> David
>
> On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> Currently, tree unrolling pass(cunroll) does not allow any code
>> size growth in O2 mode. Code size growth is permitted only if O3 or
>> funroll-loops/fpeel-loops is used. I have created a patch to allow
>> partial code size increase in O2 mode. With funroll-loops the maximum
>> allowed code growth is 400 unrolled insns. I have set it to 200
>> unrolled insns in O2 mode. This patch improves an image processing
>> benchmark by 20%. It improves most benchmarks by 1-2%. The code size
>> increase is <1% for all the benchmarks except the image processing
>> benchmark which increases by 6% (perf improves by 20%).
>>
>> I am working on getting this patch reviewed for trunk. Here is
>> the disussion on this:
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have
>> incorporated the comments on making the patch simpler. I will
>> follow-up on that patch to trunk by also getting data on limiting
>> complete peeling with O2.
>>
>> Is this ok for the google branch?
>>
>> Thanks
>> Sri
Index: params.def
===
--- params.def (revision 206638)
+++ params.def (working copy)
@@ -339,6 +339,11 @@ DEFPARAM(PARAM_MAX_COMPLETELY_PEELED_INSNS,
"max-completely-peeled-insns",
"The maximum number of insns of a completely peeled loop",
400, 0, 0)
+/* The default maximum number of insns of a peeled loop, with -O2. */
+DEFPARAM(PARAM_MAX_DEFAULT_COMPLETELY_PEELED_INSNS,
+ "max-default-completely-peeled-insns",
+ "The maximum number of insns of a completely peeled loop",
+ 200, 0, 0)
/* The maximum number of peelings of a single loop that is peeled completely.
*/
DEFPARAM(PARAM_MAX_COMPLETELY_PEEL_TIMES,
"max-completely-peel-times",
Index: opts.c
===
--- opts.c (revision 206638)
+++ opts.c (working copy)
@@ -855,6 +855,18 @@ finish_options (struct gcc_options *opts, struct g
0, opts->x_param_values, opts_set->x_param_values);
}
+ /* Set PARAM_MAX_COMPLETELY_PEELED_INSNS to the default original value during
+ -O2 when -funroll-loops and -fpeel-loops are not set. */
+ if (optimize == 2 && !opts->x_flag_unroll_loops && !opts->x_flag_peel_loops
+ && !opts->x_flag_unroll_all_loops)
+
+{
+ maybe_set_param_value
+ (PARAM_MAX_COMPLETELY_PEELED_INSNS,
+PARAM_VALUE (PARAM_MAX_DEFAULT_COMPLETELY_PEELED_INSNS),
+ opts->x_param_values, opts_set->x_param_values);
+}
+
/* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion
is disabled. */
if ((!opts->x_flag_tree_loop_vectorize && !opts->x_flag_tree_slp_vectorize)
Index: tree-ssa-loop.c
===
--- tree-ssa-loop.c (revision 206638)
+++ tree-ssa-loop.c (working copy)
@@ -467,7 +467,7 @@ tree_complete_unroll (void)
return tree_unroll_loops_completely (flag_unroll_loops
|| flag_peel_loops
- || optimize >= 3, true);
+ || optimize >= 2, true);
}
static bool
Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
ok. David On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam wrote: > On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li wrote: >> I think it might be better to introduce a new parameter for max peel >> insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or >> MAX_DEFAULT_...), and use the same logic in your patch to override the >> MAX_COMPLETELY_PEELED_INSN parameter at O2). >> >> By so doing, we don't need to have a hard coded factor of 2. > > Patch attached with that change. > > Sri > >> >> In the longer run, we really need better cost/benefit analysis, but >> that is independent. >> >> David >> >> On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam wrote: >>> Hi, >>> >>> Currently, tree unrolling pass(cunroll) does not allow any code >>> size growth in O2 mode. Code size growth is permitted only if O3 or >>> funroll-loops/fpeel-loops is used. I have created a patch to allow >>> partial code size increase in O2 mode. With funroll-loops the maximum >>> allowed code growth is 400 unrolled insns. I have set it to 200 >>> unrolled insns in O2 mode. This patch improves an image processing >>> benchmark by 20%. It improves most benchmarks by 1-2%. The code size >>> increase is <1% for all the benchmarks except the image processing >>> benchmark which increases by 6% (perf improves by 20%). >>> >>> I am working on getting this patch reviewed for trunk. Here is >>> the disussion on this: >>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have >>> incorporated the comments on making the patch simpler. I will >>> follow-up on that patch to trunk by also getting data on limiting >>> complete peeling with O2. >>> >>> Is this ok for the google branch? >>> >>> Thanks >>> Sri
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
> Just wanted to add a couple of MIPS-specific things on top of what Joseph > said: > > Matthew Fortune writes: > > The MSA patch as submitted is another variation of O32 ABI which could > > be described as O32+FP64+MSA(+nan2008) and would be link incompatible > > with both O32 and O32+FP64(+/-nan2008). The same of course applies to > > N32/N64 being link incompatible with N32/N64+FP64. This may make it > > difficult to have a small part of an application optimised with MSA > > but the rest of the code ignorant of MSA, in your experience do you > > think that will be an issue? > > FWIW, n32/n64 is always fp64 -- we don't support an fp32 version. Sorry I meant N32/N64 being link incompatible with N32/N64+MSA. > And as you imply, o32+fp64 is already an established ABI so I think we have > to support the current form alongside any new one. I agree with Joseph that > it'd be better to realign the stack dynamically instead. > This is what x86 does, so it's well tested within gcc. I see that x86 includes support for a DRAP register which as far as I can tell improves debug'ability and the generated code when dynamic stack realignment is triggered. Any thoughts on whether defining a DRAP register for MIPS would be worthwhile if we were to rely on dynamic realignment? > > Also, I think there was a possibility of adding a 256-bit form of MSA in > future, > is that right? So if we added extra static alignments, would we need a > separate ABI for 256-bit MSA too? Personally, I'd want to avoid further ABIs if MSA ever got extended to 256bit and I would expect there would also be some desire to interlink the current MSA with future extensions which would make further ABI variants undesirable. Adding extra static alignments now would therefore seem like a bad precedent to set. Going back to a point from Joseph: > * If you want to pass vector arguments (or return values) in new registers, > without affecting the ABI for any non-vector argument or return type, we're > a bit more relaxed on that - but if this affects GNU C generic vectors rather > than just architecture-specific vector types there should, at least, be a > -Wpsabi warning about the ABI change implied by enabling the vector > instructions. I assume we could define architecture specific types with the same layout as GNU C generic vectors and differentiate between the two giving the user the choice of which to use and have GNU C generic vectors stay with existing calling convention. I guess arch specific types are defined by tagging them with an attribute? > Alternatively, enable such argument passing only with an ABI > option e.g. -mmsa-abi, rather than with the same option that enables the > new instructions. In either case, you need to make sure the dynamic linker > is built with the new instructions disabled, to avoid it clobbering the new > registers (just as it generally needs special handling for call-clobbered > registers involved in argument passing). The MSA registers are not completely new but rather wider registers that overlay with the standard FP registers... I think this therefore causes further issues as use of the corresponding FP registers would clobber the MSA values even if the underlying FP registers were call-saved (the extended part of the register is zero'd when used as scalar FP). Matthew
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
> > And as you imply, o32+fp64 is already an established ABI so I think we > > have to support the current form alongside any new one. I agree with > > Joseph that it'd be better to realign the stack dynamically instead. > > This is what x86 does, so it's well tested within gcc. > > With glibc, o32+fp64 is not established - the glibc patch submitted in > November needs more work as I noted in my review, likely to include > dynamic linker names distinct from those used for o32+fp32. So it would be > possible to declare that only a new form is supported with glibc (more > generally, with the Linux kernel, given the lack of current kernel support for > o32+fp64 stated in the glibc discussion), with appropriate configure checks > preventing building glibc with an old-ABI o32+fp64 compiler (and ideally a > #error in some glibc header disallowing building programs with an old-ABI > o32+fp64 compiler). True, but it doesn't seem wise to have the 'same' ABI work differently between linux and bare metal. Code portability from linux to bare metal (and vice-versa) can be important and whilst code could be written taking the biggest stack alignment into consideration to solve such a problem it still feels wrong to have them work differently. > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: Patch committed: Fix ChangeLog entry
Thanks :) On Wed, Jan 22, 2014 at 1:15 AM, Richard Sandiford wrote: > Ian Lance Taylor writes: >> This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that >> was incorrectly added to the top-level ChangeLog file. Changes to >> ChangeLog files do not themselves get ChangeLog entries. Committed as >> obvious. > > Sorry, this was my bad, not Kito's fault at all. > > Richard >
RE: [Patch, microblaze]: Remove SECONDARY_MEMORY_NEEDED
Hi Michael, > -Original Message- > From: Michael Eager [mailto:ea...@eagerm.com] > Sent: Friday, 17 January 2014 4:44 am > To: David Holsgrove; gcc-patches@gcc.gnu.org > Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch, microblaze]: Remove SECONDARY_MEMORY_NEEDED > > On 11/25/13 23:51, David Holsgrove wrote: > > Hi Michael, > > > > I've attached patch based on latest gcc master. Please let me know if > > you need anything further. > > > > thanks, > > David > > > > On 15 July 2013 14:44, David Holsgrove wrote: > >> Hi Michael, > >> > >> On 18 March 2013 22:49, David Holsgrove > wrote: > >>> MicroBlaze doesn't have restrictions that would force us to > >>> reload regs via memory. Don't define SECONDARY_MEMORY_NEEDED. > >>> Fixes an ICE when compiling OpenSSL for linux. > >>> > >>> Changelog > >>> > >>> 2013-03-18 Edgar E. Iglesias > >>> > >>> * gcc/config/microblaze/microblaze.h: Remove > SECONDARY_MEMORY_NEEDED > >>> definition. > >>> > >>> Signed-off-by: Edgar E. Iglesias > >>> Signed-off-by: Peter A. G. Crosthwaite > >>> > >> > >> Patch remains the same, please apply when ready. > >> > >> thanks, > >> David > > Hi David -- > > Is it possible to add a test case which shows the ICE? > I'm afraid I don’t still have my test environment for this patch from last March, I'll attempt to recreate and distil into a small test case if possible, based on the error encountered whilst building openssl. I'll update again when I have some further detail. thanks, David > Thanks. > > > -- > Michael Eager ea...@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
RE: [Patch, microblaze]: Fix ICE with mhard-float
> -Original Message- > From: Michael Eager [mailto:ea...@eagerm.com] > Sent: Friday, 17 January 2014 4:36 am > To: David Holsgrove; gcc-patches@gcc.gnu.org > Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch, microblaze]: Fix ICE with mhard-float > > On 11/25/13 23:50, David Holsgrove wrote: > > Hi Michael, > > > > I've attached the same patch based on latest gcc master. > > > > Can this be applied to gcc-4_8-branch also. > > > > thanks, > > David > > > > On 15 July 2013 14:53, David Holsgrove wrote: > >> Add SImode to cstoresf4's comparison operator, prevents ICE during combine > >> rtl pass with error message; > >> > >> internal compiler error: in simplify_subreg, at simplify-rtx.c:5725 > >> > >> Use ordered_comparison_operator predicate to limit operators to > >> those fcmp can handle, and letting compiler reorder insns to > >> accommodate unordered as necessary. > >> > >> Changelog entry; > >> > >> 2013-07-15 David Holsgrove > >> > >> * gcc/config/microblaze/microblaze.md: Fix cstoresf4 and cbranchsf4 > >> > >> Can this be backported to gcc-4_8-branch also? > > > Hi David -- > > You mention that this patch fixes an ICE. Is there a failing test > case in the GCC Test Suite? Is there a GCC PR for this ICE? > If not, please add a test case to the patch. Hi Michael, Thanks for the reply. No, unfortunately there isn’t an existing test case which shows this ICE. I'm in the process of trying to recreate and distil into a small test case if possible, but the error was encountered whilst building a rather large app using microblaze linux. From the documentation though we can see that the use of comparison_operator as the predicate for these Microblaze insn patterns is too broad, as fcmp only accepts the following; http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/mb_ref_guide.pdf fcmp.un rD, rA, rB Unordered floating point comparison fcmp.lt rD, rA, rB Less-than floating point comparison fcmp.eq rD, rA, rB Equal floating point comparison fcmp.le rD, rA, rB Less-or-Equal floating point comparison fcmp.gt rD, rA, rB Greater-than floating point comparison fcmp.ne rD, rA, rB Not-Equal floating point comparison fcmp.ge rD, rA, rB Greater-or-Equal floating point comparison From gcc/gensupport.c we see that the comparison_operator predicate consists of the following expression codes; EQ, NE, LE, LT, GE, GT, LEU, LTU, GEU, GTU, UNORDERED, ORDERED, UNEQ, UNGE, UNGT, UNLE, UNLT, LTGT Whereas ordered_comparison_operator has; EQ, NE, LE, LT, GE, GT, LEU, LTU, GEU, GTU (microblaze.c's print_operand handles the unordered comparison modes before passing to fcmp) The GCC Internals documentation also highlights that ordered_comparison_operator should likely be used to restrict the possible comparison modes; http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html ‘cstoremode4’ These operations may FAIL, but should do so only in relatively uncommon cases; if they would FAIL for common cases involving integer comparisons, it is best to restrict the predicates to not allow these operands. Likewise if a given comparison operator will always fail, independent of the operands (for floating-point modes, the ordered_comparison_operator predicate is often useful in this case). > > Changelog entries saying "fix XYZ" are not as useful as a description > of the changes made. A better Changelog would be: > > * config/microblaze/microblaze.md (cstoresf4, cbranchsf4): Replace > comparison_operator with ordered_comparison_operator. > Thanks for the suggestion, yes indeed, a better ChangeLog entry would be; 2013-07-15 David Holsgrove * config/microblaze/microblaze.md (cstoresf4, cbranchsf4): Replace comparison_operator with ordered_comparison_operator. thanks again, David > > -- > Michael Eager ea...@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: PR59723: fix LTO + fortran namelist ICEs
Aldy Hernandez wrote:
>Hi folks.
>
>The problem here is that while streaming the DECL_NAME with
>stream_read_tree() and consequently lto_output_tree(), we trigger an
>ICE
>because we are recursing on the DFS walk:
>
> else
> {
> /* This is the first time we see EXPR, write all reachable
>trees to OB. */
> static bool in_dfs_walk;
>
> /* Protect against recursion which means disconnect between
> what tree edges we walk in the DFS walk and what edges
>we stream out. */
> gcc_assert (!in_dfs_walk);
>
>In the namelist fortran testcases, this is the first time we see the
>DECL_NAMEs, so we ICE. I fixed this by outputting the DECL_NAME's
>string with streamer_write_string() instead.
>
>[I honestly wondered why we don't stream the entire NAMELIST_DECL the
>same way we stream IMPORTED_DECL, all in one go, instead of piecemeal
>like the present code does. But LTO is this complicated black box in
>my
>head that I try not to think about too much...the current patch touches
>
>as little as possible.]
>
>This change alone fixes the problems in the PR, but I also found
>another
>ICE now that streaming actually works: dwarf. It turns out, that the
>way the CONSTRUCTOR elements in the NAMELIST_DECL are streamed, a
>PARM_DECL that has been previously seen (in the function's
>DECL_ARGUMENTS) will be streamed with different reference magic (or
>whatever streamed references or ids are called in LTO speak). So when
>we read the CONSTRUCTOR elements in the LTO read phase, we end up with
>different pointers for a PARM_DECL in the constructor for the seemingly
>
>same PARM_DECL in the function's arguments (DECL_ARGUMENTS).
>
>I don't understand LTO very well, but I do see that using
>stream_read_tree (lto_output_tree) caches the entries, so it seems like
>
>a good fit to avoid writing two distinct items for the same PARM_DECL.
>And since the constructor elements have been previously seen, we won't
>hit the aforementioned DFS recursion ICE.
>
>It'd be great if the LTO gods could illuminate this abyss (that's you
>Mr. Biener ;-)), but the attached patch fixes all the LTO problems
>exhibited by:
>
>make check-fortran RUNTESTFLAGS="--target_board=unix'{-flto}'
>dg.exp=*namelist*"
>
>As an aside, we really should test some subset of the LTO tests while
>testing Fortran, or this oversight will surely repeat itself on any
>changes to the Fortran streamer bits.
>
>Does this help? OK?
I'll return from vacation next week and will have a closer look then.
Richard.
>Aldy
