Re: [PATCH][SPARC] sparc: switch -fasynchronous-unwind-tables on by default.
> The backtrace(3) implementation for sparc contains a simple unwinder > that works well in most cases, but that unwinder is not used if > libgcc_s.so can be dlopened and it provides _Unwind_Backtrace. There's no reason that simple unwinder can't be put into MD_FALLBACK_FRAME_STATE_FOR. Currently we only use that for unwinding through signal stacks, but it could be used for anything that the dwarf2 unwinder doesn't have data for. Given sparc register windows, this seems particularly reliable. Sounds like a good idea. Let me prepare a patch for that...
Re: C++ PATCH to fix missing warning (PR c++/70194)
OK. Jason
[PATCH] Add debug_varinfo and debug_varmap
[ was: Re: [RFC] dump_varmap in tree-ssa-structalias.c ]
On 10/03/16 10:07, Richard Biener wrote:
On Thu, 10 Mar 2016, Tom de Vries wrote:
Hi,
I wrote attached patch to print the actual contents of the varmap variable in
tree-ssa-structalias.c.
Does it make sense to rewrite this into a dump_varmap/debug_varmap patch?
Yes (but please not dump it by default)
Right, that was my intention as well.
and I'd rather have a
split-out dump_varinfo to work with when debugging.
Done.
OK for stage1 if bootstrap and reg-test succeeds?
Thanks,
- Tom
Add debug_varinfo and debug_varmap
2016-03-16 Tom de Vries
* tree-ssa-structalias.c (dump_varinfo, debug_varinfo, dump_varmap)
(debug_varmap): New function.
---
gcc/tree-ssa-structalias.c | 108 +
1 file changed, 108 insertions(+)
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index bad1ea1..e88869f 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -682,6 +682,8 @@ void debug_constraints (void);
void debug_constraint_graph (void);
void debug_solution_for_var (unsigned int);
void debug_sa_points_to_info (void);
+void debug_varinfo (varinfo_t);
+void debug_varmap (void);
/* Print out constraint C to stderr. */
@@ -7496,6 +7498,112 @@ associate_varinfo_to_alias (struct cgraph_node *node, void *data)
return false;
}
+/* Dump varinfo VI to FILE. */
+
+static void
+dump_varinfo (FILE *file, varinfo_t vi)
+{
+ if (vi == NULL)
+return;
+
+ fprintf (file, "%u: %s\n", vi->id, vi->name);
+
+ const char *sep = " ";
+ if (vi->is_artificial_var)
+fprintf (file, "%sartificial", sep);
+ if (vi->is_special_var)
+fprintf (file, "%sspecial", sep);
+ if (vi->is_unknown_size_var)
+fprintf (file, "%sunknown-size", sep);
+ if (vi->is_full_var)
+fprintf (file, "%sfull", sep);
+ if (vi->is_heap_var)
+fprintf (file, "%sheap", sep);
+ if (vi->may_have_pointers)
+fprintf (file, "%smay-have-pointers", sep);
+ if (vi->only_restrict_pointers)
+fprintf (file, "%sonly-restrict-pointers", sep);
+ if (vi->is_restrict_var)
+fprintf (file, "%sis-restrict-var", sep);
+ if (vi->is_global_var)
+fprintf (file, "%sglobal", sep);
+ if (vi->is_ipa_escape_point)
+fprintf (file, "%sipa-escape-point", sep);
+ if (vi->is_fn_info)
+fprintf (file, "%sfn-info", sep);
+ if (vi->ruid)
+fprintf (file, "%srestrict-uid:%u", sep, vi->ruid);
+ if (vi->next)
+fprintf (file, "%snext:%u", sep, vi->next);
+ if (vi->head != vi->id)
+fprintf (file, "%shead:%u", sep, vi->head);
+ if (vi->offset)
+fprintf (file, "%soffset:" HOST_WIDE_INT_PRINT_DEC, sep, vi->offset);
+ if (vi->size != ~(unsigned HOST_WIDE_INT)0)
+fprintf (file, "%ssize:" HOST_WIDE_INT_PRINT_DEC, sep, vi->size);
+ if (vi->fullsize != ~(unsigned HOST_WIDE_INT)0
+ && vi->fullsize != vi->size)
+fprintf (file, "%sfullsize:" HOST_WIDE_INT_PRINT_DEC, sep,
+ vi->fullsize);
+ fprintf (file, "\n");
+
+ if (vi->solution && !bitmap_empty_p (vi->solution))
+{
+ bitmap_iterator bi;
+ unsigned i;
+ fprintf (file, " solution: {");
+ EXECUTE_IF_SET_IN_BITMAP (vi->solution, 0, i, bi)
+ fprintf (file, " %u", i);
+ fprintf (file, " }\n");
+}
+
+ if (vi->oldsolution && !bitmap_empty_p (vi->oldsolution)
+ && !bitmap_equal_p (vi->solution, vi->oldsolution))
+{
+ bitmap_iterator bi;
+ unsigned i;
+ fprintf (file, " oldsolution: {");
+ EXECUTE_IF_SET_IN_BITMAP (vi->oldsolution, 0, i, bi)
+ fprintf (file, " %u", i);
+ fprintf (file, " }\n");
+}
+}
+
+/* Dump varinfo VI to stderr. */
+
+DEBUG_FUNCTION void
+debug_varinfo (varinfo_t vi)
+{
+ dump_varinfo (stderr, vi);
+}
+
+/* Dump varmap to FILE. */
+
+static void
+dump_varmap (FILE *file)
+{
+ if (varmap.length () == 0)
+return;
+
+ fprintf (file, "variables:\n");
+
+ for (unsigned int i = 0; i < varmap.length (); ++i)
+{
+ varinfo_t vi = get_varinfo (i);
+ dump_varinfo (file, vi);
+}
+
+ fprintf (file, "\n");
+}
+
+/* Dump varmap to stderr. */
+
+DEBUG_FUNCTION void
+debug_varmap (void)
+{
+ dump_varmap (stderr);
+}
+
/* Execute the driver for IPA PTA. */
static unsigned int
ipa_pta_execute (void)
Re: [i386] Support .lbss etc. sections with Solaris as (PR target/59407)
On Thu, Mar 17, 2016 at 11:40 PM, Rainer Orth wrote: > gcc.target/i386/pr58218.c currently FAILs on 64-bit Solaris/x86 with the > native assembler: > > FAIL: gcc.target/i386/pr58218.c (test for excess errors) > > Excess errors: > Assembler: pr58218.c > "/var/tmp//cciHFIO7.s", line 3 : Section attributes do not match > > .section.lbss,"aw",@nobits > > It turns out x86_64 large sections need to marked with a 'h' section > flag for as. gas implicitly sets SHF_AMD64_LARGE based on section > names, but also accepts an 'l' for the same purpose. > > The following patch fixes this by using the SECTION_MACH_DEP section > flag to mark large sections and emit the right flag in > default_elf_asm_named_section. > > Given this comment in output.h > > #define SECTION_MACH_DEP 0x400 /* subsequent bits reserved for > target */ > > handling only a single SECTION_MACH_DEP can be considered a hack. > Currently, only one user of SECTION_MACH_DEP (avr) uses more than one > section flag, so maybe I can get away with this for now. > > A full solution would split out the part of > default_elf_asm_named_section that emits the flags into a new > default_elf_asm_section_flags which prints the flag string to a stream, > invoking it either via a macro than be overridden or perhaps a target > hook (which seems not fully right either since those are object file > format agnostic and this is just a small part of emitting ELF named > sections). > > The patch has been bootstrapped without regressions on > i386-pc-solaris2.12 (with both as and gas) and x86_64-pc-linux-gnu. > This is not a regression, so this may have to wait for GCC 7 stage 1. > > Ok for mainline now or then? I'd rather leave this and subsequent patch for gcc-7 at this point. The patch touches middle-end, and from the explanation above, it looks that some discussion with middle-end maintainers (relevant people CC'd) and their approval is still needed. Uros. > Thanks. > Rainer > > > 2016-03-15 Rainer Orth > > PR target/59407 > * config/i386/i386.c (SECTION_LARGE): Define. > (x86_64_elf_select_section): Set it for large data/bss sections. > Only clear SECTION_WRITE for .lrodata. > (x86_64_elf_section_type_flags): Set SECTION_LARGE for large > data/bss sections. > * config/i386/sol2.h (MACH_DEP_SECTION_ASM_FLAG): Define. > * varasm.c (default_elf_asm_named_section): Grow flagchars. > [MACH_DEP_SECTION_ASM_FLAG] Emit MACH_DEP_SECTION_ASM_FLAG for > SECTION_MACH_DEP. > * doc/tm.texi.in (Sections, MACH_DEP_SECTION_ASM_FLAG): Describe. > * doc/tm.texi: Regenerate. > > > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University >
[C++ PATCH] Fix -flifetime-dse bug in dtors too (PR c++/70272)
Hi!
This is a follow-up to the PR70259 that got fixed yesterday.
As the testcase shows, clobbers for empty classes are harmful not just in
the ctors, but also in the dtors, where they can result in stores being
removed before the corresponding dtor has acted upon them.
The ehcleanup1.C part of the patch just reverts the PR34949 adjustment
of the testcase following to addition of clobbers in dtors - it doesn't
actually make the generated code any worse.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and 5.x after a while?
2016-03-17 Jakub Jelinek
PR c++/70272
* decl.c (begin_destructor_body): Don't insert clobber if
is_empty_class (current_class_type).
* g++.dg/opt/flifetime-dse5.C (main): Remove extra semicolon.
* g++.dg/opt/flifetime-dse6.C: New test.
* g++.dg/tree-ssa/ehcleanup-1.C: Adjust unreachable count.
--- gcc/cp/decl.c.jj2016-03-17 00:12:07.0 +0100
+++ gcc/cp/decl.c 2016-03-17 11:11:04.816068299 +0100
@@ -14354,7 +14354,9 @@ begin_destructor_body (void)
initialize_vtbl_ptrs (current_class_ptr);
finish_compound_stmt (compound_stmt);
- if (flag_lifetime_dse)
+ if (flag_lifetime_dse
+ /* Clobbering an empty base is harmful if it overlays real data. */
+ && !is_empty_class (current_class_type))
{
/* Insert a cleanup to let the back end know that the object is dead
when we exit the destructor, either normally or via exception. */
--- gcc/testsuite/g++.dg/opt/flifetime-dse5.C.jj2016-03-17
00:12:06.0 +0100
+++ gcc/testsuite/g++.dg/opt/flifetime-dse5.C 2016-03-17 11:11:28.948734056
+0100
@@ -10,4 +10,4 @@ int main() {
C c;
if ( c.a == false )
__builtin_abort();
-};
+}
--- gcc/testsuite/g++.dg/opt/flifetime-dse6.C.jj2016-03-17
11:14:41.344069338 +0100
+++ gcc/testsuite/g++.dg/opt/flifetime-dse6.C 2016-03-17 11:14:32.0
+0100
@@ -0,0 +1,11 @@
+// PR c++/70272
+// { dg-options -O2 }
+// { dg-do run }
+
+struct Empty { };
+struct A { A() : a(true) { } bool a; ~A() { if (!a) __builtin_abort(); } };
+struct B : Empty { B() : Empty() { } ~B() { } };
+struct C : A, B { C() : A(), B() { } ~C() { } };
+int main() {
+ C c;
+}
--- gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C.jj 2015-05-29
15:04:33.0 +0200
+++ gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C 2016-03-17 15:01:01.267373561
+0100
@@ -26,5 +26,5 @@ t (void)
// { dg-final { scan-tree-dump-times "Empty EH handler" 2 "ehcleanup1" } }
//
// And as a result also contained control flow.
-// { dg-final { scan-tree-dump-times "Removing unreachable" 6 "ehcleanup1" } }
+// { dg-final { scan-tree-dump-times "Removing unreachable" 4 "ehcleanup1" } }
//
Jakub
Contents of PO file 'cpplib-6.1-b20160131.fr.po'
cpplib-6.1-b20160131.fr.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Fix PR c++/70121 (premature folding of const var that was implicitly captured)
On 03/10/2016 05:58 PM, Patrick Palka wrote: This patch reverses the behavior of process_outer_var_ref, so that we always implicitly capture a const variable if it's capturable, instead of always trying to first fold it to a constant. This behavior however is wrong too, and introduces a different but perhaps less important regression: if we implicitly capture by value a const object that is not actually odr-used within the body of the lambda, we may introduce a redundant call to its copy/move constructor, see pr70121-2.C. In general I'm disinclined to trade one bug for another, and I'm skeptical that the different regression is less important; I imagine that most uses of const variables will be for their constant value rather than their address. Jason
Re: C++ PATCH to fix missing warning (PR c++/70194)
On 03/17/2016 02:51 PM, Martin Sebor wrote:
On 03/17/2016 10:48 AM, Patrick Palka wrote:
On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law wrote:
On 03/16/2016 06:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec,
zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static void
+warn_for_null_address (location_t location, tree op, tsubst_flags_t
complain)
+{
...
+ if (TREE_CODE (cop) == ADDR_EXPR
+ && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
+ && !TREE_NO_WARNING (cop))
+warning_at (location, OPT_Waddress, "the address of %qD will
never "
+"be NULL", TREE_OPERAND (cop, 0));
+
+ if (CONVERT_EXPR_P (op)
+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) ==
REFERENCE_TYPE)
+{
+ tree inner_op = op;
+ STRIP_NOPS (inner_op);
+
+ if (DECL_P (inner_op))
+warning_at (location, OPT_Waddress,
+"the compiler can assume that the address of "
+"%qD will never be NULL", inner_op);
Since I noted the subtle differences between the phrasing of
the various -Waddress warnings in the bug, I have to ask: what is
the significance of the difference between the two warnings here?
Would it not be appropriate to issue the first warning in the latter
case? Or perhaps even use the same text as is already used elsewhere:
"the address of %qD will always evaluate as ‘true’" (since it may not
be the macro NULL that's mentioned in the expression).
They were added at different times AFAICT. The former is fairly old
(Douglas Gregor, 2008) at this point. The latter was added by
Patrick Palka
for 65168 about a year ago.
You could directly ask Patrick about motivations for a different
message.
There is no plausible way for the address of a non-reference variable
to be NULL even in code with UB (aside from __attribute__ ((weak)) in
which case the warning is suppressed). But the address of a reference
can easily seem to be NULL if one performs UB and assigns to it *(int
*)NULL or something like that. I think that was my motivation, anyway
:)
Thanks (everyone) for the explanation.
I actually think the warning Patrick added is the most accurate
and would be appropriate in all cases.
I suppose what bothers me besides the mention of NULL even when
there is no NULL in the code, is that a) the text of the warnings
is misleading (contradictory) in some interesting cases, and b)
I can't think of a way in which the difference between the three
phrasings of the diagnostic could be useful to a user. All three
imply the same thing: compilers can and GCC is some cases does
assume that the address of an ordinary (non weak) function, object,
or reference is not null.
To see (a), consider the invalid test program below, in which
GCC makes this assumption about the address of i even though
the warning doesn't mention it (but it makes a claim that's
contrary to the actual address), yet doesn't make the same
assumption about the address of the reference even though
the diagnostic says it can.
While I would find the warning less misleading if it simply said
in all three cases: "the address of 'x' will always evaluate as
‘true’" I think it would be even more accurate if it said
"the address of 'x' may be assumed to evaluate to ‘true’" That
avoids making claims about whether or not it actually is null,
doesn't talk about the NULL macro when one isn't used in the
code, and by saying "may assume" it allows for both making
the assumption as well as not making one.
That sounds good except that talking about 'true' is wrong when there is
an explicit comparison to a null pointer constant. I'd be fine with
changing "NULL" to "null" or similar.
I'm happy to submit a patch to make this change in stage 1 if
no one objects to it.
Martin
$ cat x.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -c -xc++ x.c &&
/home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -DMAIN -Wall -Wextra -Wpedantic
x.o -xc++ x.c && ./a.out
#if MAIN
extern int i;
extern int &r;
extern void f ();
int main ()
{
f ();
#define TEST(x) __builtin_printf ("%s is %s\n", #x, (x) ? "true" : "false")
TEST (&i != 0);
TEST (&r != 0);
TEST (&i);
}
#else
extern __attribute__ ((weak)) int i;
int &r = i;
void f ()
{
__builtin_printf ("&i = %p\n&r = %p\n", &i, &r);
}
#endif
x.c: In function ‘int main()’:
x.c:14:17: warning: the address of ‘i’ will never be NULL [-Waddress]
TEST (&i != 0);
^
x.c:12:54: note: in definition of macro ‘TEST’
#define TEST(x) __builtin_printf ("%s is %s\n", #x, (x) ? "true" :
"false")
^
x.c:15:14: warning: the compiler can assume that the address of ‘r’ will
never be NULL [-Waddress]
TEST (&r != 0);
~~~^~~~
x.c:12:54: note: in definition of macro ‘TEST’
#defi
Re: [Patch, testsuite] Skip testcase for avr
On 03/16/2016 11:33 AM, Senthil Kumar Selvaraj wrote: 2016-03-16 Senthil Kumar Selvaraj * gcc.c-torture/compile/20151204.c: Skip for avr. THanks. Applied to the trunk. jeff
Re: [PATCH][ARM][testsuite][committed] Do not override -mcpu in no-volatile-in-it.c
On 16/07/15 16:31, Kyrill Tkachov wrote: > Hi all, > > This scan-assembler test was failing for me when testing with an > explicit /-march=armv7-a variant because > it clashed with the -mcpu=cortex-m7 and overrode it. > > This patch skips the test if the user forces an incompatible -march or > -mcpu option. > The test now appears as UNSUPPORTED in these conditions and PASSes > normally. > > Applied as obvious with r225892. > > Thanks, > Kyrill > > 2015-07-16 Kyrylo Tkachov > > * gcc.target/arm/no-volatile-in-it.c: Skip if -mcpu is overriden. OK to backport this to gcc-5-branch? Cheers, Andre
[omp] Create openmp -fopt-info optimization group
Hi,
the following patch does two things. First, it creates a new optinfo
group for OpenMP and moves OpenMP lowering and expansion to this
group. Second, it changes all gridification MSG_NOTE dumps to
MSG_MISSED_OPTIMIZATION, which is more appropriate. (Apparently, I
remembered to change the dump about performed gridification to
MSG_OPTIMIZED_LOCATIONS last autumn but failed to do it for dumps with
failure reasons).
With these changes, users that configured their compiler with HSA can
use (for example) the -fopt-info-all-openmp option to get information
about which target constructs have been gridified and which were not:
mjambor@virgil:~/gcc/hsa/tests/grid$ ~/gcc/hsa/inst/bin/gcc -fopenmp -O
combined-hsa.c -fopt-info-all-openmp
combined-hsa.c:9:9: note: Target construct will be turned into a gridified
GPGPU kernel
or
/home/mjambor/gcc/hsa/src/libgomp/testsuite/libgomp.c/examples-4/target_data-3.c:50:10:
note: Will not turn target construct into a simple GPGPU kernel because it
does not have a sole teams construct in it.
and so forth.
I have bootstrapped and tested the patch on x86_64-linux (with and
without configured HSA) and by running make info and examining the
generated info files. Since it is only a dumping change, I'd like to
propose it for trunk even at this late stage. If release managers
however do not think it is desirable, I'll commit it to the hsa branch
and propose to trunk again once stage1 opens.
Thanks,
Martin
2016-03-14 Martin Jambor
* doc/invoke.texi (-fopt-info): Document openmp optimization group.
* doc/optinfo.texi (Optimization groups): Document OPTGROUP_OPENMP.
* dumpfile.c (optgroup_options): Add entry for OpenMP optimizations.
* dumpfile.h (OPTGROUP_OPENMP): New define.
* omp-low.c (pass_data_expand_omp): Change optinfo_flags to
OPTGROUP_OPENMP.
(pass_data_expand_omp_ssa): Likewise.
(pass_data_lower_omp): Likewise.
(pass_data_omp_simd_clone): Likewise.
(grid_find_single_omp_among_assignments_1): Changed all occurrences of
MSG_NOTE to MSG_MISSED_OPTIMIZATION.
(grid_find_single_omp_among_assignments): Likewise.
(grid_target_follows_gridifiable_pattern): Likewise.
---
gcc/doc/invoke.texi | 2 ++
gcc/doc/optinfo.texi | 3 +++
gcc/dumpfile.c | 1 +
gcc/dumpfile.h | 3 ++-
gcc/omp-low.c| 56 ++--
5 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 99ac11b..5c798a4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12194,6 +12194,8 @@ Enable dumps from all interprocedural optimizations.
Enable dumps from all loop optimizations.
@item inline
Enable dumps from all inlining optimizations.
+@item openmp
+Enable dumps from OpenMP optimizations.
@item vec
Enable dumps from all vectorization optimizations.
@item optall
diff --git a/gcc/doc/optinfo.texi b/gcc/doc/optinfo.texi
index 3c8fdba..20ca560 100644
--- a/gcc/doc/optinfo.texi
+++ b/gcc/doc/optinfo.texi
@@ -59,6 +59,9 @@ Loop optimization passes. Enabled by @option{-loop}.
@item OPTGROUP_INLINE
Inlining passes. Enabled by @option{-inline}.
+@item OPTGROUP_OPENMP
+OpenMP passes. Enabled by @option{-openmp}.
+
@item OPTGROUP_VEC
Vectorization passes. Enabled by @option{-vec}.
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index 144e371..f2430f3 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -136,6 +136,7 @@ static const struct dump_option_value_info
optgroup_options[] =
{"ipa", OPTGROUP_IPA},
{"loop", OPTGROUP_LOOP},
{"inline", OPTGROUP_INLINE},
+ {"openmp", OPTGROUP_OPENMP},
{"vec", OPTGROUP_VEC},
{"optall", OPTGROUP_ALL},
{NULL, 0}
diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h
index c168cbf..72f696b 100644
--- a/gcc/dumpfile.h
+++ b/gcc/dumpfile.h
@@ -97,7 +97,8 @@ enum tree_dump_index
#define OPTGROUP_LOOP(1 << 2) /* Loop optimization passes */
#define OPTGROUP_INLINE (1 << 3) /* Inlining passes */
#define OPTGROUP_VEC (1 << 4) /* Vectorization passes */
-#define OPTGROUP_OTHER (1 << 5) /* All other passes */
+#define OPTGROUP_OPENMP (1 << 5) /* OpenMP specific transformations */
+#define OPTGROUP_OTHER (1 << 6) /* All other passes */
#define OPTGROUP_ALL(OPTGROUP_IPA | OPTGROUP_LOOP | OPTGROUP_INLINE \
| OPTGROUP_VEC | OPTGROUP_OTHER)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 82dec9d..6f42717 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -13990,7 +13990,7 @@ const pass_data pass_data_expand_omp =
{
GIMPLE_PASS, /* type */
"ompexp", /* name */
- OPTGROUP_NONE, /* optinfo_flags */
+ OPTGROUP_OPENMP, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_gimple_any, /* properties_required */
PROP_gimple_eomp, /* properties_provided */
@@ -14037,7 +14037,7 @@ const pass_data pass_data_expand_omp_ssa =
{
GIMPLE_PASS
Re: Fix 70278 (LRA split_regs followup patch)
On 03/18/2016 06:25 AM, Bernd Schmidt wrote: This fixes an oversight in my previous patch here. I used biggest_mode in the assumption that if the reg was used in the function, it would be set to something other than VOIDmode, but that fails if we have a multiword access - only the first hard reg gets its biggest_mode assigned in that case. Bootstrapped and tested on x86_64-linux, ran (just) the new arm testcase manually with arm-eabi. Ok? (The testcase seems to be from glibc. Do we keep the copyright notices on the reduced form)? I don't recall specific guidance on including the copyright notice on a reduced/derived test. Given the actual copyright on the original code, ISTM the safest thing to do is keep the notice intact. A long long time ago I receive guidance from the FSF WRT what could be included in the testsuite -- unfortunately I didn't keep that message. I probably should have. Bernd 70278.diff PR rtl-optimization/70278 * lra-constraints.c (split_reg): Handle the case where biggest_mode is VOIDmode. testsuite/ * gcc.dg/torture/pr70278.c: New test. * gcc.target/arm/pr70278.c: New test. OK. jeff
[gomp-nvptx 6/7] nvptx backend: change mul.u32 to mul.lo.u32
Recent testing uncovered that PTX JIT may reject attempts to use 'mul.u32' as a non-widening 32-bit multiply instruction. Use 'mul.lo.u32' to fix 32-bit code generation and conform to the PTX spec better. * config/nvptx/nvptx.c (nvptx_init_unisimt_predicate): Emit 'mul.lo.u32' instead of 'mul.u32' for 32-bit ABI target. (nvptx_declare_function_name): Ditto. --- gcc/ChangeLog.gomp-nvptx | 6 ++ gcc/config/nvptx/nvptx.c | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c index 93bf781..bc187ea 100644 --- a/gcc/config/nvptx/nvptx.c +++ b/gcc/config/nvptx/nvptx.c @@ -955,7 +955,7 @@ nvptx_init_unisimt_predicate (FILE *file) fprintf (file, "\t\t.reg.u%d %%ustmp2;\n", bits); fprintf (file, "\t\tmov.u32 %%ustmp0, %%tid.y;\n"); fprintf (file, "\t\tmul%s.u32 %%ustmp1, %%ustmp0, 4;\n", - bits == 64 ? ".wide" : ""); + bits == 64 ? ".wide" : ".lo"); fprintf (file, "\t\tmov.u%d %%ustmp2, __nvptx_uni;\n", bits); fprintf (file, "\t\tadd.u%d %%ustmp2, %%ustmp2, %%ustmp1;\n", bits); fprintf (file, "\t\tld.shared.u32 %%r%d, [%%ustmp2];\n", master); @@ -1115,7 +1115,7 @@ nvptx_declare_function_name (FILE *file, const char *name, const_tree decl) fprintf (file, "\t.reg.u%d %%fstmp2;\n", bits); fprintf (file, "\tmov.u32 %%fstmp0, %%tid.y;\n"); fprintf (file, "\tmul%s.u32 %%fstmp1, %%fstmp0, %d;\n", - bits == 64 ? ".wide" : "", bits / 8); + bits == 64 ? ".wide" : ".lo", bits / 8); fprintf (file, "\tmov.u%d %%fstmp2, __nvptx_stacks;\n", bits); /* fstmp2 = &__nvptx_stacks[tid.y]; */ fprintf (file, "\tadd.u%d %%fstmp2, %%fstmp2, %%fstmp1;\n", bits);
Re: Please include ada-hurd.diff upstream (try2)
Sorry for manually creating this mail. Replying to Arnauds message crashes my mail client (evolution). On Wed, 2016-03-16 at 11:53 +0100, Arnaud Charlet wrote: > Yes, you are right, somehow I submitted the old patch. Attached is the > updated one, with a proposed ChangeLog entry included. > > The copyright notices are wrong (or at least incomplete). Hi, what is wrong then, copyright years and/or the text?
Re: [PATCH, PR70161] Fix fdump-ipa-all-graph
On 18/03/16 10:23, Tom de Vries wrote:
On 15/03/16 12:37, Richard Biener wrote:
On Mon, 14 Mar 2016, Tom de Vries wrote:
Hi,
this patch fixes PR70161, a 4.9/5/6 regression.
Currently when using -fdump-ipa-all-graph, the compiler ICEs in
execute_function_dump when testing for pass->graph_dump_initialized,
because
pass == NULL.
The patch fixes:
- the ICE by setting the pass argument in the call to
execute_function_dump in execute_one_ipa_transform_pass
- a subsequent ICE (triggered with -fipa-pta) by saving, resetting and
restoring dump_file_name in cgraph_node::get_body, alongside the
saving and restoring of the dump_file variable.
- the duplicate edges in the subsequently generated dot file by
ensuring that execute_function_dump is called only once per function
per pass. [ Note that this bit also has an effect for the normal dump
files for the ipa passes with transform function. For those
functions,
atm execute_function_dump is called both after execute and after
transform. With the patch, it's only called after transform. ]
Bootstrapped and reg-tested on x86_64.
OK for stage4?
Ok.
I've added these two test-cases that test the first two fixes.
Committed to trunk as obvious.
This patch adds testing for the last fix.
In order to make scanning lines in a .dot file work, I needed a fix in
dump-suffix to show cp.dot and inline.dot in the test summary:
...
PASS: gcc.dg/pr70161.c scan-ipa-dump-times cp.dot "subgraph" 1
PASS: gcc.dg/pr70161.c scan-ipa-dump-times inline.dot "subgraph" 1
...
Otherwise it would just show 'dot'.
Bootstrapped and reg-tested on x86_64.
OK for stage4 trunk, 4.9/5 release branches?
Thanks,
- Tom
Add dot-file scans to pr70161.c
2016-03-18 Tom de Vries
* gcc.dg/pr70161.c: Add dot-file scans.
* lib/scandump.exp (dump-suffix): Return suffix after first dot char,
instead of after last dot char.
---
gcc/testsuite/gcc.dg/pr70161.c | 3 +++
gcc/testsuite/lib/scandump.exp | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/pr70161.c b/gcc/testsuite/gcc.dg/pr70161.c
index 0b173c7..9b77d90 100644
--- a/gcc/testsuite/gcc.dg/pr70161.c
+++ b/gcc/testsuite/gcc.dg/pr70161.c
@@ -5,3 +5,6 @@ void
foo (void)
{
}
+
+/* { dg-final { scan-ipa-dump-times "subgraph" 1 "inline.dot" } } */
+/* { dg-final { scan-ipa-dump-times "subgraph" 1 "cp.dot" } } */
diff --git a/gcc/testsuite/lib/scandump.exp b/gcc/testsuite/lib/scandump.exp
index 74d27cc..89b3944 100644
--- a/gcc/testsuite/lib/scandump.exp
+++ b/gcc/testsuite/lib/scandump.exp
@@ -22,7 +22,7 @@
# Extract the constant part of the dump file suffix from the regexp.
# Argument 0 is the regular expression.
proc dump-suffix { arg } {
-set idx [expr [string last "." $arg] + 1]
+set idx [expr [string first "." $arg] + 1]
return [string range $arg $idx end]
}
Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression
On Wed, Mar 16, 2016 at 01:38:21PM -0600, Jeff Law wrote: > On 03/14/2016 04:13 PM, Jakub Jelinek wrote: > >On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote: > >>PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end > >>of array fails inside constant expression > >>PR c++/70170 - [6 regression] bogus not a constant expression error > >>comparing > >>pointer to array to null > >>PR c++/70172 - incorrect reinterpret_cast from integer to pointer error > >>on invalid constexpr initialization > >>PR c++/60760 - arithmetic on null pointers should not be allowed in constant > >>expressions > >>PR c++/70228 - insufficient detail in diagnostics for a constexpr out of > >>bounds > >>array subscript > > > >Can you please check up the formatting in the patch? > >Seems e.g. you've replaced tons of tabs with 8 spaces etc. (check your > >editor setting, and check the patch with contrib/check-GNU-style.sh). > >There is some trailing whitespace too, spaces before [, etc. > Jakub, do you have any comments on the substance of the patch? If so, it > would help immensely if you could provide them so that Martin could address > technical issues at the same time as he fixes up whitespace nits. No, I'll defer technical comments to Jason. The formatting is just something that caught my eye during the 10 seconds or so spent on reading the patch flying by. Jakub
Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic
On Thu, Mar 17, 2016 at 8:23 AM, Bernd Schmidt wrote: > On 03/17/2016 04:13 PM, H.J. Lu wrote: >> >> On Thu, Mar 17, 2016 at 8:09 AM, Bernd Schmidt >> wrote: >>> >>> On 03/17/2016 04:06 PM, H.J. Lu wrote: This is the patch I am going to check in. >>> >>> That still mentions darwin which I imagine might not be an exhaustive >>> test. >> >> >> We can add an effective target, something like ignore_pic_pie, and >> use it instead of *-*-darwin*. > > > That should have been done _before_ committing the patch in a form that was > not approved. > How should we move forward? -- H.J.
[PATCH] Change replace_rtx if from is a REG (PR target/70245, take 2)
Hi!
On Wed, Mar 16, 2016 at 05:48:33PM -0500, Segher Boessenkool wrote:
> On Wed, Mar 16, 2016 at 01:59:29PM +0100, Bernd Schmidt wrote:
> > On 03/16/2016 01:22 PM, Jakub Jelinek wrote:
> > >So, this is what we've converged to on IRC and passed bootstrap/regtest
> > >on x86_64-linux and i686-linux. Is this ok for trunk?
> >
> > The explanation was a bit confusing at first, but I think this looks
> > reasonable. The assert worries me, but triggering it would indicate a
> > potential miscompilation, so I think it is preferrable to have it.
>
> This caused PR70261. Maybe it's just the assert.
Unfortunately it is not just the assert, and it is on various targets.
On powerpc64, one issue is during combiner, where we most likely don't
strictly care if we replace all, but can't replace one with bad mode and
can run into that case, and then during prologue threading, where
the rs6000 backend for whatever strange reason I haven't understood
really wants pointer equality instead of REGNO comparison (even when the
modes match), one (reg:DI 12) should be replaced, another (reg:DI 12)
should not.
Thus, I've reverted the patch (kept the testcase), and after some
discussions on IRC bootstrapped/regtested on x86_64-linux and i686-linux
following version, which right now should change behavior just for the i?86
case and nothing else, so shouldn't break other targets.
I believe at least the epiphany and sh peepholes that use replace_rtx will
want similar treatment, but will leave testing of that to their maintainers.
Ok for trunk?
2016-03-17 Jakub Jelinek
PR target/70245
* rtl.h (replace_rtx): Add ALL_REGS argument.
* rtlanal.c (replace_rtx): Likewise. If true, use REGNO
equality and assert mode is the same, instead of just rtx pointer
equality.
* config/i386/i386.md (mov + arithmetics with load peephole): Pass
true as ALL_REGS argument to replace_rtx.
--- gcc/rtl.h.jj2016-03-16 10:36:36.0 +0100
+++ gcc/rtl.h 2016-03-17 10:05:53.144242638 +0100
@@ -3011,7 +3011,7 @@ extern bool can_nonlocal_goto (const rtx
extern void copy_reg_eh_region_note_forward (rtx, rtx_insn *, rtx);
extern void copy_reg_eh_region_note_backward (rtx, rtx_insn *, rtx);
extern int inequality_comparisons_p (const_rtx);
-extern rtx replace_rtx (rtx, rtx, rtx);
+extern rtx replace_rtx (rtx, rtx, rtx, bool = false);
extern void replace_label (rtx *, rtx, rtx, bool);
extern void replace_label_in_insn (rtx_insn *, rtx, rtx, bool);
extern bool rtx_referenced_p (const_rtx, const_rtx);
--- gcc/rtlanal.c.jj2016-03-17 08:59:37.0 +0100
+++ gcc/rtlanal.c 2016-03-17 10:16:42.870241836 +0100
@@ -2946,10 +2946,13 @@ inequality_comparisons_p (const_rtx x)
not enter into CONST_DOUBLE for the replace.
Note that copying is not done so X must not be shared unless all copies
- are to be modified. */
+ are to be modified.
+
+ ALL_REGS is true if we want to replace all REGs equal to FROM, not just
+ those pointer-equal ones. */
rtx
-replace_rtx (rtx x, rtx from, rtx to)
+replace_rtx (rtx x, rtx from, rtx to, bool all_regs)
{
int i, j;
const char *fmt;
@@ -2961,9 +2964,17 @@ replace_rtx (rtx x, rtx from, rtx to)
if (x == 0)
return 0;
- if (GET_CODE (x) == SUBREG)
+ if (all_regs
+ && REG_P (x)
+ && REG_P (from)
+ && REGNO (x) == REGNO (from))
+{
+ gcc_assert (GET_MODE (x) == GET_MODE (from));
+ return to;
+}
+ else if (GET_CODE (x) == SUBREG)
{
- rtx new_rtx = replace_rtx (SUBREG_REG (x), from, to);
+ rtx new_rtx = replace_rtx (SUBREG_REG (x), from, to, all_regs);
if (CONST_INT_P (new_rtx))
{
@@ -2979,7 +2990,7 @@ replace_rtx (rtx x, rtx from, rtx to)
}
else if (GET_CODE (x) == ZERO_EXTEND)
{
- rtx new_rtx = replace_rtx (XEXP (x, 0), from, to);
+ rtx new_rtx = replace_rtx (XEXP (x, 0), from, to, all_regs);
if (CONST_INT_P (new_rtx))
{
@@ -2997,10 +3008,11 @@ replace_rtx (rtx x, rtx from, rtx to)
for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
{
if (fmt[i] == 'e')
- XEXP (x, i) = replace_rtx (XEXP (x, i), from, to);
+ XEXP (x, i) = replace_rtx (XEXP (x, i), from, to, all_regs);
else if (fmt[i] == 'E')
for (j = XVECLEN (x, i) - 1; j >= 0; j--)
- XVECEXP (x, i, j) = replace_rtx (XVECEXP (x, i, j), from, to);
+ XVECEXP (x, i, j) = replace_rtx (XVECEXP (x, i, j),
+ from, to, all_regs);
}
return x;
--- gcc/config/i386/i386.md.jj 2016-03-16 10:36:36.0 +0100
+++ gcc/config/i386/i386.md 2016-03-17 10:09:01.281636259 +0100
@@ -17885,7 +17885,7 @@ (define_peephole2
(parallel [(set (match_dup 0)
(match_op_dup 3 [(match_dup 0) (match_dup 1)]))
(clobber (reg:CC FLAGS_REG))])]
- "operands[4] = replace_rtx (operands[2], operands[0], operands[1]);")
+ "operands[4] = re
Re: [PATCH] Fix PR64764
On Mon, Feb 9, 2015 at 2:30 AM, Tom de Vries wrote:
> On 09-02-15 09:59, Richard Biener wrote:
>>
>> On Thu, 5 Feb 2015, Tom de Vries wrote:
>>
>>> On 26-01-15 15:47, Richard Biener wrote:
Index: gcc/testsuite/gcc.dg/uninit-19.c
===
--- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
+++ gcc/testsuite/gcc.dg/uninit-19.c(working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wuninitialized" } */
+
+int a, l, m;
+float *b;
+float c, d, e, g, h;
+unsigned char i, k;
+void
+fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float
*f4,
+ unsigned char *c2, float *p10)
+{
+ if (p1 & 8)
+b[3] = p10[a]; /* { dg-warning "may be used uninitialized" } */
+}
+
+void
+fn2 ()
+{
+ float *n;
+ if (l & 6)
+n = &c + m;
+ fn1 (l, &d, &e, &g, &i, &h, &k, n);
+}
>>>
>>>
>>> Hi Richard,
>>>
>>> this new test fails with -fpic, because fn1 is not inlined.
>>>
>>> Adding static to fn1 allows it to pass both with and without -fpic. But
>>> that
>>> change might affect whether it still serves as a regression test for this
>>> PR,
>>> I'm not sure.
>>>
>>> Another way to fix this could be to use the warning line number 22
>>> instead 13
>>> for fpic.
>>
>>
>> Either way is fine with me.
>>
>
> Committed using the method of different line number for -fpic.
>
> Thanks,
> - Tom
>
> 2015-02-09 Tom de Vries
>
> * gcc.dg/uninit-19.c: Fix warning line for fpic.
> ---
> gcc/testsuite/gcc.dg/uninit-19.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/uninit-19.c
> b/gcc/testsuite/gcc.dg/uninit-19.c
> index 3113cab..fc7acea 100644
> --- a/gcc/testsuite/gcc.dg/uninit-19.c
> +++ b/gcc/testsuite/gcc.dg/uninit-19.c
> @@ -10,7 +10,7 @@ fn1 (int p1, float *f1, float *f2, float *f3, unsigned
> char *c1, float *f4,
> unsigned char *c2, float *p10)
> {
>if (p1 & 8)
> -b[3] = p10[a]; /* { dg-warning "may be used uninitialized" } */
> +b[3] = p10[a]; /* 13. */
> }
>
> void
> @@ -19,5 +19,8 @@ fn2 ()
>float *n;
>if (l & 6)
> n = &c + m;
> - fn1 (l, &d, &e, &g, &i, &h, &k, n);
> + fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
> }
> +
> +/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
> +/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 }
> */
> --
> 1.9.1
>
Any particular reason why this test was changed to DOS format?
--
H.J.
Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245)
On Wed, Mar 16, 2016 at 01:59:29PM +0100, Bernd Schmidt wrote: > On 03/16/2016 01:22 PM, Jakub Jelinek wrote: > >So, this is what we've converged to on IRC and passed bootstrap/regtest > >on x86_64-linux and i686-linux. Is this ok for trunk? > > The explanation was a bit confusing at first, but I think this looks > reasonable. The assert worries me, but triggering it would indicate a > potential miscompilation, so I think it is preferrable to have it. This caused PR70261. Maybe it's just the assert. Segher
Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes
On 03/17/2016 12:23 PM, Bernd Schmidt wrote: On 03/17/2016 06:37 PM, Jeff Law wrote: + bitmap seen_insns; + seen_insns = BITMAP_ALLOC (NULL); You could save an allocation here by making this a bitmap_head and using bitmap_initialize. I guess so, but it's one allocation per compiled function and doesn't leak. Using bitmap_initialize would introduce a conditional in the loop + bitmap_set_bit (seen_insns, INSN_UID (insn)); + if (! INSN_P (insn)) continue; @@ -3646,7 +3656,8 @@ update_equiv_regs (void) && ! find_reg_note (XEXP (reg_equiv[regno].init_insns, 0), REG_EQUIV, NULL_RTX) && ! contains_replace_regs (XEXP (dest, 0)) - && ! pdx_subregs[regno]) + && ! pdx_subregs[regno] + && ! bitmap_bit_p (seen_insns, INSN_UID (insn))) This looks odd to me. Isn't this condition always false? Did you want to test the init_insn? You're right. Egad. Which indirectly argues that this code in and of itself needs some test coverage to verify that it fires when it's supposed to. So, I'm off to find & reduce a test where this code triggers correctly. :-) jeff
Re: [Patch, testsuite] Skip testcase for avr
Rainer Orth writes:
> Hi Senthil,
>
>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20151204.c
>> b/gcc/testsuite/gcc.c-torture/compile/20151204.c
>> index 036316c..0a60871 100644
>> --- a/gcc/testsuite/gcc.c-torture/compile/20151204.c
>> +++ b/gcc/testsuite/gcc.c-torture/compile/20151204.c
>> @@ -1,3 +1,5 @@
>> +/* { dg-skip-if "Array too big" { "avr-*-*" } { "*" } { "" } } */
>
> just one nit: please omit the default args to dg-skip-if, they are
> unnecessary.
>
Done.
gcc/testsuite/ChangeLog
2016-03-16 Senthil Kumar Selvaraj
* gcc.c-torture/compile/20151204.c: Skip for avr.
diff --git gcc/testsuite/gcc.c-torture/compile/20151204.c
gcc/testsuite/gcc.c-torture/compile/20151204.c
index 036316c..e07e13d 100644
--- gcc/testsuite/gcc.c-torture/compile/20151204.c
+++ gcc/testsuite/gcc.c-torture/compile/20151204.c
@@ -1,3 +1,5 @@
+/* { dg-skip-if "Array too big" { "avr-*-*" } } */
+
typedef __SIZE_TYPE__ size_t;
int strcmp (const char*, const char*);
Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245, take 2)
On Thu, Mar 17, 2016 at 12:16:58PM +0100, Jakub Jelinek wrote: > the rs6000 backend for whatever strange reason I haven't understood > really wants pointer equality instead of REGNO comparison (even when the > modes match), one (reg:DI 12) should be replaced, another (reg:DI 12) > should not. By the look of what you posted in the bugzilla, the pattern is the parallel emitted by rs6000_emit_savres_rtx. In that parallel, the stack memory locations for register saves are described relative to whatever frame_reg_rtx is in use, which may be r12. rs6000_frame_related wants to translate the frame_reg_rtx into stack pointer plus offset for debug info. The parallel matches save_gpregs__r12 and similar in rs6000.md, which emit a call to an out-of-line register save function. This function actually takes r12 as a parameter, hence the (use (reg:P 12)) in the pattern. rs6000_frame_related probably should just be replacing individual SETs in the parallel using simplify_replace_rtx. Especially since after calling replace_rtx, it already iterates over them to simplify. -- Alan Modra Australia Development Lab, IBM
Re: [05/05] Fix PR 69102
On 03/15/2016 09:55 AM, Andrey Belevantsev wrote: Hello, On 14.03.2016 12:52, Andrey Belevantsev wrote: Hello, The problem here is readonly dependence contexts in selective scheduler. We're trying to cache the effect of initializing a dependence context with remembering that context and setting a readonly bit on it. When first moving the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax set) we also set the last_args_size field of the context. Later, when we make a copy of insn 43 and try to move it again through insn 3, we take the cached dependency context and notice the (fake) dep with last_args_size insn, which is the old insn 43. Then the assert saying that we should be able to lift the bookkeeping copy up the same way as we did with the original insn breaks. Fixed by the attached patch that makes us notice only deps with the current producer insn. Ok for trunk? We've discussed the patch with Alexander a bit and decided to take the different approach. The core issue here is not handling the new last_args_size field in the readonly contexts. In general, the readonly context approach, when analyzing an insn with a readonly context, would create the necessary dependencies with all of the last_ fields but refrain from modifying those fields. The reason is we need to capture the effect of only the single producer in the readonly context. Failing to do so may update the last_ fields with the effect of subsequent analyses and having the fake dependencies with the insns that got into those fields instead of having the dependencies with the currently used producer. So the right fix here is to guard setting of the last_args_size field with !deps->readonly test as it is done elsewhere in the sched-deps.c. In stage 1 we will also want to set the asserts in the sel-sched dependency hooks (where I have placed early returns in the previous version of the patch) actually checking that the dependency is always created with the current producer, and such cases will be caught sooner. The new patch bootstrapped and tested on x86-64 with selective scheduler forced enabled with no regressions. It needs the maintainer outside of sel-sched as we touch sched-deps.c file. Ok for trunk? The test is the same as in previous patch. Andrey 2016-03-15 Andrey Belevantsev PR rtl-optimization/69102 * sched-deps.c (sched_analyze_insn): Do not set last_args_size field when we have a readonly dependency context. gcc/ 2016-03-14 Andrey Belevantsev PR rtl-optimization/69102 * sel-sched.c (has_dependence_note_dep): Only take into account dependencies produced by the current producer insn. (has_dependence_note_mem_dep): Likewise. testsuite/ 2016-03-14 Andrey Belevantsev PR rtl-optimization/69102 * gcc.c-torture/compile/pr69102.c: New test. OK. jeff
Re: C++ PATCH to fix missing warning (PR c++/70194)
On Wed, Mar 16, 2016 at 06:43:39PM -0600, Martin Sebor wrote:
> >@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
> >return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
> > }
> >
> >+/* Possibly warn about an address never being NULL. */
> >+
> >+static void
> >+warn_for_null_address (location_t location, tree op, tsubst_flags_t
> >complain)
> >+{
> ...
> >+ if (TREE_CODE (cop) == ADDR_EXPR
> >+ && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
> >+ && !TREE_NO_WARNING (cop))
> >+warning_at (location, OPT_Waddress, "the address of %qD will never "
> >+"be NULL", TREE_OPERAND (cop, 0));
> >+
> >+ if (CONVERT_EXPR_P (op)
> >+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) == REFERENCE_TYPE)
> >+{
> >+ tree inner_op = op;
> >+ STRIP_NOPS (inner_op);
> >+
> >+ if (DECL_P (inner_op))
> >+warning_at (location, OPT_Waddress,
> >+"the compiler can assume that the address of "
> >+"%qD will never be NULL", inner_op);
>
> Since I noted the subtle differences between the phrasing of
> the various -Waddress warnings in the bug, I have to ask: what is
> the significance of the difference between the two warnings here?
Quite frankly, I don't know.
> Would it not be appropriate to issue the first warning in the latter
> case? Or perhaps even use the same text as is already used elsewhere:
> "the address of %qD will always evaluate as ‘true’" (since it may not
> be the macro NULL that's mentioned in the expression).
There are more discrepancies in the front ends wrt error/warning messages.
Perhaps we should try to unify them some more, but I don't think this has
a big priority, if the message is clear enough for the users.
Marek
[PATCH] PR testsuite/70150: Check non-pic/ia32 in stackprotectexplicit2.C
For ia32, __stack_chk_fail isn't called in PIC. We need to check
non-pic or non-ia32 before scanning for __stack_chk_fail.
OK for trunk?
H.J.
---
PR testsuite/70150
* g++.dg/stackprotectexplicit2.C: Scanning for __stack_chk_fail
only for non-pic or non-ia32 .
---
gcc/testsuite/g++.dg/stackprotectexplicit2.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/stackprotectexplicit2.C
b/gcc/testsuite/g++.dg/stackprotectexplicit2.C
index 9cf9ab9..e30b4b3 100644
--- a/gcc/testsuite/g++.dg/stackprotectexplicit2.C
+++ b/gcc/testsuite/g++.dg/stackprotectexplicit2.C
@@ -24,4 +24,4 @@ int __attribute__((stack_protect)) c()
}
-/* { dg-final { scan-assembler-times "stack_chk_fail" 2 } } */
\ No newline at end of file
+/* { dg-final { scan-assembler-times "stack_chk_fail" 2 { target { nonpic || {
! ia32 } } } } } */
--
2.5.0
Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic
On Thu, Mar 17, 2016 at 7:55 AM, H.J. Lu wrote:
> On Thu, Mar 17, 2016 at 7:18 AM, Bernd Schmidt wrote:
>> On 03/17/2016 02:59 PM, H.J. Lu wrote:
>>>
>>> On Fri, Mar 11, 2016 at 9:09 AM, H.J. Lu wrote:
We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie. We need
to initialize flag_pic to -1 so that we can tell if -fpic, -fPIC,
-fno-pic or -fno-PIC is used.
>>
>>
PR driver/70192
* opts.c (finish_options): Don't set flag_pie to the default if
-fpic, -fPIC, -fno-pic or -fno-PIC is used. Set flag_pic to 0
if it is -1.
>>
>>
>> I think this part is ok.
>>
diff --git a/gcc/testsuite/gcc.dg/pie-2.c b/gcc/testsuite/gcc.dg/pie-2.c
new file mode 100644
index 000..e185e51
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pie-2.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-fPIE" } */
+
+#if __PIC__ != 2
+# error __PIC__ is not 2!
+#endif
+
+#if __PIE__ != 2
+# error __PIE__ is not 2!
+#endif
>>
>>
>> In normal code that should probably use the "__PIC__ - 0" trick to guard
>> against cases where the macro isn't defined, but I suppose we'd be getting
>> an error in that case as well.
>>
>>
diff --git a/gcc/testsuite/gcc.dg/pie-3.c b/gcc/testsuite/gcc.dg/pie-3.c
new file mode 100644
index 000..fe46c98
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pie-3.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-pie" } */
+
+#ifdef __PIC__
+# error __PIC__ is defined!
+#endif
+
+#ifdef __PIE__
+# error __PIE__ is defined!
+#endif
diff --git a/gcc/testsuite/gcc.dg/pie-4.c b/gcc/testsuite/gcc.dg/pie-4.c
new file mode 100644
index 000..977baf0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pie-4.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-PIE" } */
+
+#ifdef __PIC__
+# error __PIC__ is defined!
+#endif
+
+#ifdef __PIE__
+# error __PIE__ is defined!
+#endif
>>
diff --git a/gcc/testsuite/gcc.dg/pie-6.c b/gcc/testsuite/gcc.dg/pie-6.c
new file mode 100644
index 000..85529a8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pie-6.c
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { ! pie_enabled } } } */
+/* { dg-options "" } */
+
+#ifdef __PIC__
+# error __PIC__ is defined!
+#endif
+
+#ifdef __PIE__
+# error __PIE__ is defined!
+#endif
>>
>> These I'm not so sure about. I could imagine there are targets where pic is
>> the default. I'd remove these tests or the test for __PIC__. So, ok with
>> that change.
>
> Darwin is such a target. Here is a follow-up patch I was planning to
> submit. But I will remove __PIC__ instead.
>
This is the patch I am going to check in.
Thanks.
--
H.J.
From a19696e2f4e6f9734baa29c7833cd029eafa93fe Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 11 Mar 2016 09:02:56 -0800
Subject: [PATCH] Properly set flag_pie and flag_pic
We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie. We need
to initialize flag_pic to -1 so that we can tell if -fpic, -fPIC,
-fno-pic or -fno-PIC is used.
Since Darwin defaults to PIC (__PIC__ == 2) and the PIC setting can't
be changed, skip tests of default __PIC__ and __PIE__ setting for
*-*-darwin* targets.
gcc/
PR driver/70192
* opts.c (finish_options): Don't set flag_pie to the default if
-fpic, -fPIC, -fno-pic or -fno-PIC is used. Set flag_pic to 0
if it is -1.
gcc/testsuite/
PR driver/70192
* gcc.dg/pic-1.c: New test.
* gcc.dg/pic-2.c: Likewise.
* gcc.dg/pic-3.c: Likewise.
* gcc.dg/pic-4.c: Likewise.
* gcc.dg/pie-1.c: Likewise.
* gcc.dg/pie-2.c: Likewise.
* gcc.dg/pie-3.c: Likewise.
* gcc.dg/pie-4.c: Likewise.
* gcc.dg/pie-5.c: Likewise.
* gcc.dg/pie-6.c: Likewise.
---
gcc/common.opt | 4 ++--
gcc/opts.c | 7 ++-
gcc/testsuite/gcc.dg/pic-1.c | 10 ++
gcc/testsuite/gcc.dg/pic-2.c | 10 ++
gcc/testsuite/gcc.dg/pic-3.c | 10 ++
gcc/testsuite/gcc.dg/pic-4.c | 10 ++
gcc/testsuite/gcc.dg/pie-1.c | 10 ++
gcc/testsuite/gcc.dg/pie-2.c | 10 ++
gcc/testsuite/gcc.dg/pie-3.c | 10 ++
gcc/testsuite/gcc.dg/pie-4.c | 10 ++
gcc/testsuite/gcc.dg/pie-5.c | 10 ++
gcc/testsuite/gcc.dg/pie-6.c | 6 ++
12 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pic-1.c
create mode 100644 gcc/testsuite/gcc.dg/pic-2.c
create mode 100644 gcc/testsuite/gcc.dg/pic-3.c
create mode 100644 gcc/testsui
Re: [PATCH] Fix PR c++/70205 (ICE on valid call to qualified static member function)
OK. Jason
Re: [PATCH][ARM][5 Backport] PR target/69875 Fix atomic_loaddi expansion
On Wed, Feb 24, 2016 at 11:23 AM, Kyrill Tkachov wrote: > Hi all, > > This is the GCC 5 backport of > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01338.html. > The differences are that TARGET_HAVE_LPAE has to be defined in arm.h in a > different way because > the ARM_FSET_HAS_CPU1 mechanism doesn't exist on this branch. > Also, the scan-assembler tests that check for the DMB instruction are > updated to check for > "dmb sy" rather than "dmb ish", because the memory barrier instruction > changed on trunk for GCC 6. > > Bootstrapped and tested on the GCC 5 branch on arm-none-linux-gnueabihf. > > Ok for the branch after the trunk patch has had a few days to bake? > OK. Ramana > Thanks, > Kyrill > > 2016-02-24 Kyrylo Tkachov > > PR target/69875 > * config/arm/arm.h (TARGET_HAVE_LPAE): Define. > * config/arm/unspecs.md (VUNSPEC_LDRD_ATOMIC): New value. > * config/arm/sync.md (arm_atomic_loaddi2_ldrd): New pattern. > (atomic_loaddi_1): Delete. > (atomic_loaddi): Rewrite expander using the above changes. > > 2016-02-24 Kyrylo Tkachov > > PR target/69875 > * gcc.target/arm/atomic_loaddi_acquire.x: New file. > * gcc.target/arm/atomic_loaddi_relaxed.x: Likewise. > * gcc.target/arm/atomic_loaddi_seq_cst.x: Likewise. > * gcc.target/arm/atomic_loaddi_1.c: New test. > * gcc.target/arm/atomic_loaddi_2.c: Likewise. > * gcc.target/arm/atomic_loaddi_3.c: Likewise. > * gcc.target/arm/atomic_loaddi_4.c: Likewise. > * gcc.target/arm/atomic_loaddi_5.c: Likewise. > * gcc.target/arm/atomic_loaddi_6.c: Likewise. > * gcc.target/arm/atomic_loaddi_7.c: Likewise. > * gcc.target/arm/atomic_loaddi_8.c: Likewise. > * gcc.target/arm/atomic_loaddi_9.c: Likewise.
Re: [AArch64] Add precision choices for the reciprocal square root approximation
Hi Evandro, > For example, though this approximation is improves the performance > noticeably for DF on A57, for SF, not so much, if at all. I'm still skeptical that you ever can get any gain on scalars. I bet the only gain is on 4x vectorized floats. So what I would like to see is this implemented in a more general way. We should be able choose whether to expand depending on the mode - including whether it is vectorized. For example enable on V4SFmode and maybe V2DFmode, but not on any scalars. Then we'd add new CPU tuning settings for division, sqrt and rsqrt (rather than adding lots of extra tune flags). Note the md file should call a function in aarch64.c to decide whether to expand or not (your division approximation patch makes the decision in the md file which does not seem a good idea). Wilco
[PATCH V2]PR other/70268: map one directory name (old) to another (new) in __FILE__
Changed in V2:
- Rebase to latest master (f958b9e9d4dfed811f36217c800194dd82becf01)
- Fix incorrect PR in libcpp/ChangeLog and gcc/ChangeLog
//Hongxu
>From b8761da98466242e1d18b4e39eb0ea3c6cee4d73 Mon Sep 17 00:00:00 2001
From: Hongxu Jia
Date: Wed, 16 Mar 2016 04:55:56 -0700
Subject: [PATCH V2] map one directory name (old) to another (new) in __FILE__
PR other/70268
* gcc/c-family/c.opt(-ffile-prefix-map=): New option.
* gcc/c-family/c-opts.c: Include file-map.h
(c_common_handle_option): Handle -ffile-prefix-map.
* gcc/gimplify.c: Include file-map.h
(gimplify_call_expr): Call remap_file_filename
* gcc/dwarf2out.c (gen_producer_string): Ignore -ffile-prefix-map.
* libcpp/macro.c: Include file-map.h
(_cpp_builtin_macro_text): Call remap_file_filename
* libcpp/include/file-map.h (remap_file_filename,
add_file_prefix_map): Declare.
* libcpp/file-map.c: Include config.h, system.h, file-map.h.
(struct file_prefix_map, file_prefix_maps, add_file_prefix_map,
remap_file_filename): New.
* libcpp/Makefile.in (file-map.c, file-map.o,
file-map.h): Update dependencies.
* doc/invoke.texi (-ffile-prefix-map): Document.
Signed-off-by: Hongxu Jia
---
gcc/ChangeLog | 10 ++
gcc/c-family/c-opts.c | 6
gcc/c-family/c.opt| 4 +++
gcc/doc/invoke.texi | 6
gcc/dwarf2out.c | 1 +
gcc/gimplify.c| 2 ++
libcpp/ChangeLog | 13 +++
libcpp/Makefile.in| 10 +++---
libcpp/file-map.c | 92 +++
libcpp/include/file-map.h | 30
libcpp/macro.c| 2 ++
11 files changed, 171 insertions(+), 5 deletions(-)
create mode 100644 libcpp/file-map.c
create mode 100644 libcpp/include/file-map.h
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 00bc1a6..085a727 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2016-03-17 Hongxu Jia
+
+ PR other/70268
+ * c-family/c-opts.c: Include file-map.h
+ (c_common_handle_option): Handle -ffile-prefix-map.
+ * c-family/c.opt(-ffile-prefix-map=): New option.
+ * gimplify.c: Include file-map.h
+ (gimplify_call_expr): Call remap_file_filename
+ * dwarf2out.c (gen_producer_string): Ignore -ffile-prefix-map.
+
2016-03-17 Jakub Jelinek
PR target/70261
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index fec58bc..4dab155 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include "plugin.h" /* For PLUGIN_INCLUDE_FILE event. */
#include "mkdeps.h"
#include "dumpfile.h"
+#include "file-map.h"
#ifndef DOLLARS_IN_IDENTIFIERS
# define DOLLARS_IN_IDENTIFIERS true
@@ -503,6 +504,11 @@ c_common_handle_option (size_t scode, const char *arg, int value,
cpp_opts->narrow_charset = arg;
break;
+case OPT_ffile_prefix_map_:
+ if (add_file_prefix_map(arg) < 0)
+error ("invalid argument %qs to -ffile-prefix-map", arg);
+ break;
+
case OPT_fwide_exec_charset_:
cpp_opts->wide_charset = arg;
break;
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 7c5f6c7..2b88874 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1204,6 +1204,10 @@ fexec-charset=
C ObjC C++ ObjC++ Joined RejectNegative
-fexec-charset= Convert all strings and character constants to character set .
+ffile-prefix-map=
+C ObjC C++ ObjC++ Joined RejectNegative
+-ffile-prefix-map= Map one directory name to another in __FILE__, __BASE_FILE__ and __builtin_FILE()
+
fextended-identifiers
C ObjC C++ ObjC++
Permit universal character names (\\u and \\U) in identifiers.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 99ac11b..d45d85f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -323,6 +323,7 @@ Objective-C and Objective-C++ Dialects}.
-gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf @gol
-gvms -gxcoff -gxcoff+ -gz@r{[}=@var{type}@r{]} @gol
-fdebug-prefix-map=@var{old}=@var{new} -fdebug-types-section @gol
+-ffile-prefix-map=@var{old}=@var{new} @gol
-feliminate-dwarf2-dups -fno-eliminate-unused-debug-types @gol
-femit-struct-debug-baseonly -femit-struct-debug-reduced @gol
-femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
@@ -5929,6 +5930,11 @@ link processing time. Merging is enabled by default.
When compiling files in directory @file{@var{old}}, record debugging
information describing them as in @file{@var{new}} instead.
+@item -ffile-prefix-map=@var{old}=@var{new}
+@opindex ffile-prefix-map
+When parsing __FILE__, __BASE_FILE__ and __builtin_FILE(), use directory
+@file{@var{new}} to replace @file{@var{old}}.
+
@item -fvar-tracking
@opindex fvar-tracking
Run variable tracking pass. It computes where variables are stored at each
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 61bf267..d8beeea 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -21672,6 +21672,7 @@ gen_producer_string (void)
case OPT_fltrans_output_list_:
[committed] PR c/70264: fix crash in compatible_locations_p with BUILTINS_LOCATION
In r234088 my fix for PR c++/70105 didn't allow for the possibility that
when comparing a pair of macro expansion histories that one of the
macros in the history might not be located within a line-map, and
PR c/70264 reports a crash due to encountering BUILTINS_LOCATION within
the traversal.
Fixed thusly.
Successfully bootstrapped on x86_64-pc-linux-gnu; adds 4 PASS results
to gcc.sum and 12 to g++.sum.
Committed to trunk as r234303.
gcc/ChangeLog:
PR c/70264
* diagnostic-show-locus.c (compatible_locations_p): Handle the case
where one or both locations aren't within a line_map.
gcc/testsuite/ChangeLog:
PR c/70264
* c-c++-common/pr70264.c: New test case.
---
gcc/diagnostic-show-locus.c | 6 ++
gcc/testsuite/c-c++-common/pr70264.c | 13 +
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/c-c++-common/pr70264.c
diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 55ee6b6..6314675 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -490,6 +490,12 @@ compatible_locations_p (location_t loc_a, location_t loc_b)
if (IS_ADHOC_LOC (loc_b))
loc_b = get_location_from_adhoc_loc (line_table, loc_b);
+ /* If either location is one of the special locations outside of a
+ linemap, they are only compatible if they are equal. */
+ if (loc_a < RESERVED_LOCATION_COUNT
+ || loc_b < RESERVED_LOCATION_COUNT)
+return loc_a == loc_b;
+
const line_map *map_a = linemap_lookup (line_table, loc_a);
linemap_assert (map_a);
diff --git a/gcc/testsuite/c-c++-common/pr70264.c
b/gcc/testsuite/c-c++-common/pr70264.c
new file mode 100644
index 000..815aad1
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr70264.c
@@ -0,0 +1,13 @@
+/* { dg-options "-fdiagnostics-show-caret" } */
+
+#define X __LINE__ /* { dg-error "expected" } */
+X
+
+/* { dg-begin-multiline-output "" }
+ #define X __LINE__
+ ^
+ { dg-end-multiline-output "" } */
+/* { dg-begin-multiline-output "" }
+ X
+ ^
+ { dg-end-multiline-output "" } */
--
1.8.5.3
Re: C++ PATCH to fix missing warning (PR c++/70194)
On 03/16/2016 08:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static void
+warn_for_null_address (location_t location, tree op, tsubst_flags_t
complain)
+{
...
+ if (TREE_CODE (cop) == ADDR_EXPR
+ && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
+ && !TREE_NO_WARNING (cop))
+warning_at (location, OPT_Waddress, "the address of %qD will never "
+"be NULL", TREE_OPERAND (cop, 0));
+
+ if (CONVERT_EXPR_P (op)
+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) == REFERENCE_TYPE)
+{
+ tree inner_op = op;
+ STRIP_NOPS (inner_op);
+
+ if (DECL_P (inner_op))
+warning_at (location, OPT_Waddress,
+"the compiler can assume that the address of "
+"%qD will never be NULL", inner_op);
Since I noted the subtle differences between the phrasing of
the various -Waddress warnings in the bug, I have to ask: what is
the significance of the difference between the two warnings here?
The difference is that in the second case, a reference could be bound to
a null address, but that has undefined behavior, so the compiler can
assume it won't happen.
Jason
[oacc, testsuite, comitted] Add goacc/kernels-alias-{3,4}.f95
Hi,
I've translated the goacc/kernels-alias-{3,4}.c testcases to fortran.
Committed to trunk.
Thanks,
- Tom
Add goacc/kernels-alias-{3,4}.f95
2016-03-17 Tom de Vries
* gfortran.dg/goacc/kernels-alias-3.f95: New test.
* gfortran.dg/goacc/kernels-alias-4.f95: New test.
---
gcc/testsuite/gfortran.dg/goacc/kernels-alias-3.f95 | 19 +++
gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95 | 20
2 files changed, 39 insertions(+)
diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-alias-3.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-alias-3.f95
new file mode 100644
index 000..56f3d59
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/kernels-alias-3.f95
@@ -0,0 +1,19 @@
+! { dg-additional-options "-O2" }
+! { dg-additional-options "-fdump-tree-ealias-all" }
+
+program main
+ implicit none
+ integer, target :: a
+ integer, pointer :: ptr
+ ptr => a
+
+ !$acc kernels pcopyin (a, ptr)
+ a = 0
+ ptr = 1
+ !$acc end kernels
+
+end program main
+
+! Only the omp_data_i related loads should be annotated with cliques.
+! { dg-final { scan-tree-dump-times "clique 1 base 1" 2 "ealias" } }
+! { dg-final { scan-tree-dump-times "(?n)clique .* base .*" 2 "ealias" } }
diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95
new file mode 100644
index 000..e65253b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95
@@ -0,0 +1,20 @@
+! { dg-additional-options "-O2" }
+! { dg-additional-options "-fdump-tree-ealias-all" }
+
+program main
+ implicit none
+ integer, parameter :: n = 2
+ integer, target, dimension (0:n-1) :: a
+ integer, pointer :: ptr(:)
+ ptr => a
+
+ !$acc kernels pcopyin (a, ptr(0:2))
+ a(0) = 0
+ ptr(0) = 1
+ !$acc end kernels
+
+end program main
+
+! Only the omp_data_i related loads should be annotated with cliques.
+! { dg-final { scan-tree-dump-times "clique 1 base 1" 3 "ealias" } }
+! { dg-final { scan-tree-dump-times "(?n)clique .* base .*" 3 "ealias" } }
Re: [PATCH][ARM][4.9 Backport] PR target/69875 Fix atomic_loaddi expansion
On Wed, Feb 24, 2016 at 11:23 AM, Kyrill Tkachov wrote: > Hi all, > > This is the GCC 4.9 backport of > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01338.html. > The differences are that TARGET_HAVE_LPAE has to be defined in arm.h in a > different way because > the ARM_FSET_HAS_CPU1 mechanism doesn't exist on this branch. Also, due to > the location of insn_flags > and the various FL_* (on the 4.9 branch they're defined locally in arm.c > rather than in arm-protos.h) > I chose to define TARGET_HAVE_LPAE in terms of hardware divide instruction > availability. This should be > an equivalent definition. > > Also, the scan-assembler tests that check for the DMB instruction are > updated to check for > "dmb sy" rather than "dmb ish", because the memory barrier instruction > changed on trunk for GCC 6. > > Bootstrapped and tested on the GCC 4.9 branch on arm-none-linux-gnueabihf. > > > Ok for the branch after the trunk patch has had a few days to bake? OK. Ramana > > Thanks, > Kyrill > > 2016-02-24 Kyrylo Tkachov > > PR target/69875 > * config/arm/arm.h (TARGET_HAVE_LPAE): Define. > * config/arm/unspecs.md (VUNSPEC_LDRD_ATOMIC): New value. > * config/arm/sync.md (arm_atomic_loaddi2_ldrd): New pattern. > (atomic_loaddi_1): Delete. > (atomic_loaddi): Rewrite expander using the above changes. > > 2016-02-24 Kyrylo Tkachov > > PR target/69875 > * gcc.target/arm/atomic_loaddi_acquire.x: New file. > * gcc.target/arm/atomic_loaddi_relaxed.x: Likewise. > * gcc.target/arm/atomic_loaddi_seq_cst.x: Likewise. > * gcc.target/arm/atomic_loaddi_1.c: New test. > * gcc.target/arm/atomic_loaddi_2.c: Likewise. > * gcc.target/arm/atomic_loaddi_3.c: Likewise. > * gcc.target/arm/atomic_loaddi_4.c: Likewise. > * gcc.target/arm/atomic_loaddi_5.c: Likewise. > * gcc.target/arm/atomic_loaddi_6.c: Likewise. > * gcc.target/arm/atomic_loaddi_7.c: Likewise. > * gcc.target/arm/atomic_loaddi_8.c: Likewise. > * gcc.target/arm/atomic_loaddi_9.c: Likewise.
Re: [AArch64] Emit square root using the Newton series
On 03/08/16 16:08, Evandro Menezes wrote: On 02/16/16 14:56, Evandro Menezes wrote: On 12/08/15 15:35, Evandro Menezes wrote: Emit square root using the Newton series 2015-12-03 Evandro Menezes gcc/ * config/aarch64/aarch64-protos.h (aarch64_emit_swsqrt): Declare new function. * config/aarch64/aarch64-simd.md (sqrt2): New expansion and insn definitions. * config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNE_FAST_SQRT): New tuning macro. * config/aarch64/aarch64.c (aarch64_emit_swsqrt): Define new function. * config/aarch64/aarch64.md (sqrt2): New expansion and insn definitions. * config/aarch64/aarch64.opt (mlow-precision-recip-sqrt): Expand option description. * doc/invoke.texi (mlow-precision-recip-sqrt): Likewise. This patch extends the patch that added support for implementing x^-1/2 using the Newton series by adding support for x^1/2 as well. Is it OK at this point of stage 3? Thank you, James, As I was saying, this patch results in some validation errors in CPU2000 benchmarks using DF. Although proving the algorithm to be pretty solid with a vast set of random values, I'm confused why some benchmarks fail to validate with this implementation of the Newton series for square root too, when they pass with the Newton series for reciprocal square root. Since I had no problems with the same algorithm on x86-64, I wonder if the initial estimate on AArch64, which offers just 8 bits, whereas x86-64 offers 11 bits, has to do with it. Then again, the algorithm iterated 1 less time on x86-64 than on AArch64. Since it seems that the initial estimate is sufficient for CPU2000 to validate when using SF, I'm leaning towards restricting the Newton series for square root only for SF. Your thoughts on the matter are appreciated, Add choices for the reciprocal square root approximation Allow a target to prefer such operation depending on the FP precision. gcc/ * config/aarch64/aarch64-protos.h (AARCH64_EXTRA_TUNE_APPROX_RSQRT): New macro. * config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNE_APPROX_RSQRT_DF): New mask. (AARCH64_EXTRA_TUNE_APPROX_RSQRT_SF): Likewise. * config/aarch64/aarch64.c (use_rsqrt_p): New argument for the mode. (aarch64_builtin_reciprocal): Devise mode from builtin. (aarch64_optab_supported_p): New argument for the mode. Now that the patch is attached, feedback is appreciated. Ping. -- Evandro Menezes
Re: Patch ping
OK. Jason
[AArch64] Add precision choices for the reciprocal square root approximation
Add precision choices for the reciprocal square root approximation Allow a target to prefer such operation depending on the FP precision. gcc/ * config/aarch64/aarch64-protos.h (AARCH64_EXTRA_TUNE_APPROX_RSQRT): New macro. * config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNE_APPROX_RSQRT_DF): New mask. (AARCH64_EXTRA_TUNE_APPROX_RSQRT_SF): Likewise. * config/aarch64/aarch64.c (use_rsqrt_p): New argument for the mode. (aarch64_builtin_reciprocal): Devise mode from builtin. (aarch64_optab_supported_p): New argument for the mode. This patch allows a target to choose for which FP precision the reciprocal square root approximation is used. For example, though this approximation is improves the performance noticeably for DF on A57, for SF, not so much, if at all. Feedback appreciated. Thank you, -- Evandro Menezes
Re: [C PATCH] Prevent -Wunused-value warning with __atomic_fetch_* (PR c/69407)
On Mon, Mar 7, 2016 at 2:34 PM, Marek Polacek wrote:
> On Fri, Mar 04, 2016 at 07:17:46PM +0100, Uros Bizjak wrote:
>> Hello!
>>
>> > This is not a regression but I thought I'd post this anyway. Martin
>> > reported
>> > that we generate -Wunused-value warnings on the attached testcase, which
>> > arguable doesn't make sense. Setting TREE_USED suppresses the warning.
>> > Since
>> > we already compute 'fetch_op' I used that. (This warning doesn't trigger
>> > e.g.
>> > for __atomic_load/store/compare.)
>> >
>> > Bootstrapped/regtested on x86_64-linux, ok for trunk or gcc7?
>> >
>> > 2016-03-04 Marek Polacek
>> >
>> > PR c/69407
>> > * c-common.c (resolve_overloaded_builtin): Set TREE_USED for the fetch
>> > operations.
>> >
>> > * gcc.dg/atomic-op-6.c: New test.
>>
>> You can probably revert my workaround [1] that suppressed these
>> warnings in libsupc++/guard.cc.
>
> Ah, thanks for the heads-up, I'll do that once I get the patch in.
I have committed the attached revert after bootstrap on
x86_64-linux-gnu {,-m32}. There were no warnings when compiling
guard.cc.
2016-03-18 Uros Bizjak
Revert:
2015-07-02 Uros Bizjak
* libsupc++/guard.cc (__test_and_acquire): Use __p after __atomic_load
to avoid unused variable warning.
(__set_and_release): Use __p after __atomic_store to avoid unused
variable warning.
Uros.
Index: libsupc++/guard.cc
===
--- libsupc++/guard.cc (revision 234330)
+++ libsupc++/guard.cc (working copy)
@@ -117,7 +117,6 @@ __test_and_acquire (__cxxabiv1::__guard *g)
unsigned char __c;
unsigned char *__p = reinterpret_cast(g);
__atomic_load (__p, &__c, __ATOMIC_ACQUIRE);
- (void) __p;
return _GLIBCXX_GUARD_TEST(&__c);
}
# define _GLIBCXX_GUARD_TEST_AND_ACQUIRE(G) __test_and_acquire (G)
@@ -133,7 +132,6 @@ __set_and_release (__cxxabiv1::__guard *g)
unsigned char *__p = reinterpret_cast(g);
unsigned char val = 1;
__atomic_store (__p, &val, __ATOMIC_RELEASE);
- (void) __p;
}
# define _GLIBCXX_GUARD_SET_AND_RELEASE(G) __set_and_release (G)
# endif
[PATCH] Change replace_rtx if from is a REG (PR target/70245)
Hi!
The following testcase is miscompiled on ia32, because
a peephole2 calls replace_rtx trying to replace SImode %ecx with
SImode %edx, but replace_rtx (unlike e.g. simplify_replace_rtx
or validate_replace_rtx), in addition to modifying the rtxes
in place (fine in this case) only does pointer equality check
- if (x == from) return to;, which doesn't work well especially
on hard registers, where they could be different e.g. because
of different ORIGINAL_REGNO, REG_EXPR etc., but still have
the same mode and same REGNO. Using simplify_replace_rtx
in that peephole2 is possible, but there is a risk that function
simplifies something, turning it from a previously valid address
to invalid one, so it would have to be accomodated with
a validation check and FAIL from the peephole. Similarly,
validate_replace_rtx needs an instruction, but the peephole2 doesn't have
one yet (and again would need FAIL handling).
If it was just one peephole2 in i386 backend, I'd certainly change just
that, but looking around, at least 2 other targets use replace_rtx
in peephole2s, and quite a few backends use replace_rtx in various places,
so maybe it is better to change replace_rtx to cope with that.
So, this is what we've converged to on IRC and passed bootstrap/regtest
on x86_64-linux and i686-linux. Is this ok for trunk?
Or is replace_rtx really meant to do pointer equality comparison only and
shall we add another similar function that e.g. supports only hard reg
-> hard reg replacements without simplifications? What about the case
when the hard reg appears in the expression, but with different mode?
Would that always be the bug of the caller, or shall we do something
different in that case?
2016-03-16 Jakub Jelinek
Richard Biener
PR target/70245
* rtlanal.c (replace_rtx): For REG, if from is a REG,
return to even if only REGNO is equal, and assert
mode is the same.
* g++.dg/opt/pr70245.C: New test.
* g++.dg/opt/pr70245.h: New file.
* g++.dg/opt/pr70245-aux.cc: New file.
--- gcc/rtlanal.c.jj2016-03-16 10:36:36.0 +0100
+++ gcc/rtlanal.c 2016-03-16 10:37:19.317571738 +0100
@@ -2961,7 +2961,16 @@ replace_rtx (rtx x, rtx from, rtx to)
if (x == 0)
return 0;
- if (GET_CODE (x) == SUBREG)
+ if (GET_CODE (x) == REG)
+{
+ if (GET_CODE (from) == REG
+ && REGNO (x) == REGNO (from))
+ {
+ gcc_assert (GET_MODE (x) == GET_MODE (from));
+ return to;
+ }
+}
+ else if (GET_CODE (x) == SUBREG)
{
rtx new_rtx = replace_rtx (SUBREG_REG (x), from, to);
--- gcc/testsuite/g++.dg/opt/pr70245.C.jj 2016-03-16 09:02:11.263150597
+0100
+++ gcc/testsuite/g++.dg/opt/pr70245.C 2016-03-16 10:38:02.40896 +0100
@@ -0,0 +1,52 @@
+// PR target/70245
+// { dg-do run }
+// { dg-additional-sources "pr70245-aux.cc" }
+// { dg-options "-O2" }
+// { dg-additional-options "-fPIC" { target fpic } }
+// { dg-additional-options "-march=i386 -mtune=atom" { target ia32 } }
+
+#include "pr70245.h"
+
+struct A *a, *i;
+int b, c, e, l;
+F d;
+
+static A *
+foo (B *x, int *y, int *z)
+{
+ unsigned char *f = (unsigned char *) fn3 (y);
+ D *g = (D *) f;
+ A *h;
+ if (e || a || c || b || g->d)
+return 0;
+ h = (A *) fn4 ();
+ __builtin_memcpy (h, a, sizeof (A));
+ h->a1 = *(D *) f;
+ if (d)
+{
+ d (h, x, f + g->d, z);
+ if (*z)
+ fn2 ();
+}
+ return h;
+}
+
+static A *
+bar (B *x, int *y)
+{
+ int *j = fn1 (x->b, y);
+ if (*y > 0)
+return 0;
+ i = foo (x, j, y);
+ return i;
+}
+
+B k;
+
+void
+baz (int x)
+{
+ if (x)
+bar (0, 0);
+ bar (&k, &l);
+}
--- gcc/testsuite/g++.dg/opt/pr70245.h.jj 2016-03-16 09:02:17.073069217
+0100
+++ gcc/testsuite/g++.dg/opt/pr70245.h 2016-03-15 20:19:37.0 +0100
@@ -0,0 +1,14 @@
+extern struct A *a, *i;
+extern int b, c, e, l;
+int *fn1 (char *, int *);
+void fn2 ();
+void *fn3 (int *);
+struct B { char *b; };
+typedef void (*F) (A *, B *, unsigned char *, int *);
+struct C { int c[16]; };
+struct D { int d; };
+struct A { D a1; C a2; };
+void *fn4 ();
+extern F d;
+extern B k;
+extern void baz (int);
--- gcc/testsuite/g++.dg/opt/pr70245-aux.cc.jj 2016-03-16 09:02:14.113110677
+0100
+++ gcc/testsuite/g++.dg/opt/pr70245-aux.cc 2016-03-16 09:05:04.803719815
+0100
@@ -0,0 +1,56 @@
+// PR target/70245
+// { dg-do compile }
+// { dg-options "" }
+
+#include "pr70245.h"
+
+D m;
+A n, o;
+int p, q;
+
+int *
+fn1 (char *x, int *y)
+{
+ *y = 0;
+ return &p;
+}
+
+void
+fn2 ()
+{
+ __builtin_abort ();
+}
+
+void *
+fn3 (int *x)
+{
+ *x = 0;
+ return (void *) &m;
+}
+
+void *
+fn4 ()
+{
+ a = &o;
+ o.a1.d = 9;
+ m.d = sizeof (D);
+ __builtin_memcpy (o.a2.c, "abcdefghijklmnop", 16);
+ return (void *) &n;
+}
+
+void
+fn5 (A *x, B *y, unsigned char *z, int *w)
+{
+ if (x != &n || y != &k || z != (unsigned char *) (&m + 1))
+__builtin_abort ();
+ q++;
+}
+
+int
+main ()
+{
+ d = fn5;
+ baz (0);
Re: Wonly-top-basic-asm
On 3/14/2016 8:28 AM, Bernd Schmidt wrote:
The example is not good, as discussed previously, and IMO the best
option is to remove it. Otherwise I have no objections to the latest
variant.
Despite the problems I have with the existing sample, adding the
information/warnings is more important to me, and more valuable to
users. Perhaps we can revisit the sample when pr24414 gets addressed.
I have removed my changes to the sample in the attached patch.
ChangeLog:
2016-03-16 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers.
dw
Index: extend.texi
===
--- extend.texi (revision 234245)
+++ extend.texi (working copy)
@@ -7441,7 +7441,8 @@
@end table
@subsubheading Remarks
-Using extended @code{asm} typically produces smaller, safer, and more
+Using extended @code{asm} (@pxref{Extended Asm}) typically produces smaller,
+safer, and more
efficient code, and in most cases it is a better solution than basic
@code{asm}. However, there are two situations where only basic @code{asm}
can be used:
@@ -7481,10 +7482,25 @@
symbol errors during compilation if your assembly code defines symbols or
labels.
-Since GCC does not parse the @var{AssemblerInstructions}, it has no
-visibility of any symbols it references. This may result in GCC discarding
-those symbols as unreferenced.
+@strong{Warning:} The C standards do not specify semantics for @code{asm},
+making it a potential source of incompatibilities between compilers. These
+incompatibilities may not produce compiler warnings/errors.
+GCC does not parse basic @code{asm}'s @var{AssemblerInstructions}, which
+means there is no way to communicate to the compiler what is happening
+inside them. GCC has no visibility of symbols in the @code{asm} and may
+discard them as unreferenced. It also does not know about side effects of
+the assembler code, such as modifications to memory or registers. Unlike
+some compilers, GCC assumes that no changes to either memory or registers
+occur. This assumption may change in a future release.
+
+To avoid complications from future changes to the semantics and the
+compatibility issues between compilers, consider replacing basic @code{asm}
+with extended @code{asm}. See
+@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to convert
+from basic asm to extended asm} for information about how to perform this
+conversion.
+
The compiler copies the assembler instructions in a basic @code{asm}
verbatim to the assembly language output file, without
processing dialects or any of the @samp{%} operators that are available with
Re: Please include ada-hurd.diff upstream (try2)
> Yes, you are right, somehow I submitted the old patch. Attached is the > updated one, with a proposed ChangeLog entry included. The copyright notices are wrong (or at least incomplete). Arno > > Thanks! > 2016-03-16 Svante Signell > > * gcc-interface/Makefile.in: Add support for x86 GNU/Hurd. > * s-osinte-gnu.ads: New specification file. > * s-osinte-gnu.adb: New body file, basically > s-osinte-posix.adb > adding dummy implementation of functions not yet implemented.
[PING] [PATCH] c++/65579 - set readonly bit on static constexpr members of templates
I'm looking for a review of the patch below. The problem isn't new (it has existed since at least 4.9) but the fix seems trivial and safe. If it isn't appropriate at this stage please let me know and I'll resubmit it when stage 1 opens. https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00593.html Thanks Martin On 03/09/2016 03:09 PM, Martin Sebor wrote: While going through constexpr bugs looking for background on one I'm currently working on I came across bug 65579 - [C++11] gcc requires definition of a static constexpr member even though it is not odr-used. The bug points out that GCC (sometimes) emits references to static constexpr data members of class templates even when they aren't odr-used. (A more detailed analysis of why this happens is in my comment #1 on the bug.) The attached rather trivial patch seems to fix the problem and (somewhat to my surprise) pass regression tests on x86_64. Martin
[gomp-nvptx 3/7] libgomp plugin: make cuMemFreeHost error non-fatal
Unlike cuMemFree and other resource-releasing functions called on exit,
cuMemFreeHost appears to re-report errors encountered in kernel launch.
This leads to a deadlock after GOMP_PLUGIN_fatal is reentered.
While the behavior on libgomp side is suboptimal (there's no need to
call resource-releasing functions if we're about to destroy the CUDA
context anyway), this behavior on cuMemFreeHost part is not useful
and just makes error "recovery" harder. This was reported to NVIDIA
(bug ref. 1737876), but we can work around it by simply reporting the
error without making it fatal.
* plugin/plugin-nvptx.c (map_fini): Make cuMemFreeHost error non-fatal.
---
libgomp/ChangeLog.gomp-nvptx | 4
libgomp/plugin/plugin-nvptx.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index adf57b1..4e44242 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -135,7 +135,7 @@ map_fini (struct ptx_stream *s)
r = cuMemFreeHost (s->h);
if (r != CUDA_SUCCESS)
-GOMP_PLUGIN_fatal ("cuMemFreeHost error: %s", cuda_error (r));
+GOMP_PLUGIN_error ("cuMemFreeHost error: %s", cuda_error (r));
}
static void
[COMMITTED] Fix 70240
As discussed in the PR, the fix for 68215 was a bit too aggressive and caused
this one. There's a simple alternate fix, first suggested by Richi in 68714,
that cures both.
Thus I apply one patch and revert another, in order, so that nothing breaks in
between yet keeps the two commits separate.
Tested on i686 and x86_64 linux.
Committed as approved in the PR,
r~
PR middle-end/70240
PR middle-end/68215
PR tree-opt/68714
* gimplify.c (gimplify_expr) [VEC_COND_EXPR]: Gimplify the
first operand as is_gimple_condexpr.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 84ce46e..f3e5c39 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -10799,8 +10799,23 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
goto expr_2;
}
- case FMA_EXPR:
case VEC_COND_EXPR:
+ {
+ enum gimplify_status r0, r1, r2;
+
+ r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
+post_p, is_gimple_condexpr, fb_rvalue);
+ r1 = gimplify_expr (&TREE_OPERAND (*expr_p, 1), pre_p,
+post_p, is_gimple_val, fb_rvalue);
+ r2 = gimplify_expr (&TREE_OPERAND (*expr_p, 2), pre_p,
+post_p, is_gimple_val, fb_rvalue);
+
+ ret = MIN (MIN (r0, r1), r2);
+ recalculate_side_effects (*expr_p);
+ }
+ break;
+
+ case FMA_EXPR:
case VEC_PERM_EXPR:
/* Classified as tcc_expression. */
goto expr_3;
--
2.1.0
PR middle-end/70240
PR middle-end/68215
Revert r231575
2015-12-11 Eric Botcazou
* tree-vect-generic.c (tree_vec_extract): Remove GSI parameter.
Do not gimplify the result.
(do_unop): Adjust call to tree_vec_extract.
(do_binop): Likewise.
(do_compare): Likewise.
(do_plus_minus): Likewise.
(do_negate): Likewise.
(expand_vector_condition): Likewise.
(do_cond): Likewise.
diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index fd3dc43..cb15a95 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -103,7 +103,8 @@ typedef tree (*elem_op_func) (gimple_stmt_iterator *,
tree);
static inline tree
-tree_vec_extract (tree type, tree t, tree bitsize, tree bitpos)
+tree_vec_extract (gimple_stmt_iterator *gsi, tree type,
+ tree t, tree bitsize, tree bitpos)
{
if (TREE_CODE (t) == SSA_NAME)
{
@@ -114,21 +115,22 @@ tree_vec_extract (tree type, tree t, tree bitsize, tree bitpos)
&& gimple_assign_rhs_code (def_stmt) == CONSTRUCTOR)))
t = gimple_assign_rhs1 (def_stmt);
}
-
if (bitpos)
{
if (TREE_CODE (type) == BOOLEAN_TYPE)
{
tree itype
= build_nonstandard_integer_type (tree_to_uhwi (bitsize), 0);
- tree field = fold_build3 (BIT_FIELD_REF, itype, t, bitsize, bitpos);
- return fold_build2 (NE_EXPR, type, field, build_zero_cst (itype));
+ tree field = gimplify_build3 (gsi, BIT_FIELD_REF, itype, t,
+ bitsize, bitpos);
+ return gimplify_build2 (gsi, NE_EXPR, type, field,
+ build_zero_cst (itype));
}
-
- return fold_build3 (BIT_FIELD_REF, type, t, bitsize, bitpos);
+ else
+ return gimplify_build3 (gsi, BIT_FIELD_REF, type, t, bitsize, bitpos);
}
-
- return fold_build1 (VIEW_CONVERT_EXPR, type, t);
+ else
+return gimplify_build1 (gsi, VIEW_CONVERT_EXPR, type, t);
}
static tree
@@ -136,7 +138,7 @@ do_unop (gimple_stmt_iterator *gsi, tree inner_type, tree a,
tree b ATTRIBUTE_UNUSED, tree bitpos, tree bitsize,
enum tree_code code, tree type ATTRIBUTE_UNUSED)
{
- a = tree_vec_extract (inner_type, a, bitsize, bitpos);
+ a = tree_vec_extract (gsi, inner_type, a, bitsize, bitpos);
return gimplify_build1 (gsi, code, inner_type, a);
}
@@ -146,9 +148,9 @@ do_binop (gimple_stmt_iterator *gsi, tree inner_type, tree a, tree b,
tree type ATTRIBUTE_UNUSED)
{
if (TREE_CODE (TREE_TYPE (a)) == VECTOR_TYPE)
-a = tree_vec_extract (inner_type, a, bitsize, bitpos);
+a = tree_vec_extract (gsi, inner_type, a, bitsize, bitpos);
if (TREE_CODE (TREE_TYPE (b)) == VECTOR_TYPE)
-b = tree_vec_extract (inner_type, b, bitsize, bitpos);
+b = tree_vec_extract (gsi, inner_type, b, bitsize, bitpos);
return gimplify_build2 (gsi, code, inner_type, a, b);
}
@@ -167,8 +169,8 @@ do_compare (gimple_stmt_iterator *gsi, tree inner_type, tree a, tree b,
tree cst_true = build_all_ones_cst (stype);
tree cmp;
- a = tree_vec_extract (inner_type, a, bitsize, bitpos);
- b = tree_vec_extract (inner_type, b, bitsize, bitpos);
+ a = tree_vec_extract (gsi, inner_type, a, bitsize, bitpos);
+ b = tree_vec_extract (gsi, inner_type, b, bitsize, bitpos);
cmp = build2 (code, boolean_type_node, a, b);
return gimplify_build3 (gsi, COND_EXPR, stype, cmp, cst_true, cst_false);
@@ -200,8 +202,8 @@ do_plus_minus (gimple_stmt_iterator *gsi, tree word_type, tree a, tree b,
low_bits = build_replicated_const (word_type, inner_type, max >> 1);
high_bits = build_replicated_const (word_type, inner_type, max & ~(max >> 1));
- a = tree_vec_extract (word_type, a, bitsize, bitpos);
- b = tree_vec_extract (word_type, b, bitsize, bitpos)
Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes
On 03/17/2016 06:37 PM, Jeff Law wrote: + bitmap seen_insns; + seen_insns = BITMAP_ALLOC (NULL); You could save an allocation here by making this a bitmap_head and using bitmap_initialize. + bitmap_set_bit (seen_insns, INSN_UID (insn)); + if (! INSN_P (insn)) continue; @@ -3646,7 +3656,8 @@ update_equiv_regs (void) && ! find_reg_note (XEXP (reg_equiv[regno].init_insns, 0), REG_EQUIV, NULL_RTX) && ! contains_replace_regs (XEXP (dest, 0)) - && ! pdx_subregs[regno]) + && ! pdx_subregs[regno] + && ! bitmap_bit_p (seen_insns, INSN_UID (insn))) This looks odd to me. Isn't this condition always false? Did you want to test the init_insn? Bernd
[C PATCH] Fix up composite_types (PR c/70280)
Hi!
Zdenek reported a compare debug issue, where it is dumping used function
prototypes and there is a difference between -g0 and -g in
-2: static int BIO_vsnprintf (char *, size_t, const char *, struct *, void,
...);
+2: static int BIO_vsnprintf (char *, size_t, const char *, struct *);
The former is of course wrong, and the reason for that is that C FE's
composite_type mishandles void_list_node - that should terminate the list
if there are no varargs, it is not a void argument or something similar,
and if the original lists are terminated by that, the new one should be too.
Testcase is not included, as it is too large and reduction didn't work very
well for that.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-03-17 Jakub Jelinek
PR c/70280
* c-typeck.c (composite_type): Don't count void_list_node
into len, if the list is terminated by void_list_node, start
with void_list_node instead of NULL for newargs. Stop
at void_list_node.
--- gcc/c/c-typeck.c.jj 2016-03-16 18:15:28.0 +0100
+++ gcc/c/c-typeck.c2016-03-17 18:14:58.840886755 +0100
@@ -518,15 +518,17 @@ composite_type (tree t1, tree t2)
/* If both args specify argument types, we must merge the two
lists, argument by argument. */
- len = list_length (p1);
- newargs = 0;
+ for (len = 0, newargs = p1;
+newargs && newargs != void_list_node;
+len++, newargs = TREE_CHAIN (newargs))
+ ;
for (i = 0; i < len; i++)
newargs = tree_cons (NULL_TREE, NULL_TREE, newargs);
n = newargs;
- for (; p1;
+ for (; p1 && p1 != void_list_node;
p1 = TREE_CHAIN (p1), p2 = TREE_CHAIN (p2), n = TREE_CHAIN (n))
{
/* A null type means arg type is not specified.
Jakub
Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression
On 03/17/2016 03:16 PM, Martin Sebor wrote: static tree cxx_eval_constant_expression (const constexpr_ctx *, tree, - bool, bool *, bool *, tree * = NULL); + bool, bool *, bool *, bool * = NULL, + tree * = NULL); I didn't look deeply, but do you end up fixing all (most) of the callers of cxx_eval_constant_expression? If so, then you don't need the default initialization. Thanks for the comments. The patch only modifies about 10 out of the 70 or so calls to the function in the file and the default argument helps avoid making the rest of the changes. (I have some ideas for improving the APIs of these functions that I'd like to run by Jason when we're done with the 6.0 work.) OK. Then let's keep the default initialization. The difficulty I've run into with detecting these problems in later phases is that some invalid expressions have already been simplified by the front end. The example that applies here (even though this is still the front end) is this: Yea. I was hoping that the delayed folding work would be helping in getting a more faithful representation out of the front-ends. constexpr int* p = 0; constexpr bool b0 = &p[0] == 0; // accepted constexpr bool b1 = &p[1] == 0; // rejected Both b0 and b1 are invalid and should be diagnosed, but only b1 is. b1 isn't because because by the time we see its initializer in constexpr.c it's been transformed into the equivalent of "b1 = (int*)ps" (though we don't see the cast which would also make it invalid). But if we can avoid these early simplifying transformations and retain a more faithful representation of the original source then doing the checking later will likely be simpler and result in detecting more problems with greater consistency and less effort. Do we know where the folding is happening for this case and is it something we can reasonably defer?ie, is this just a case we missed as part of the deferred folding work and hence should have its own distinct BZ to track? Hmm, I thought we already had code to do this somewhere. It looks like it's moved around quite a bit. I think you want to be using symtab_node::nonzero_address to determine if a given symbol must bind to a nonzero address. Thanks for the hint. I had looked for existing functions but couldn't find one that worked. decl_with_nonnull_addr_p() in c-common.c looked promising but it's not accessible here and it doesn't do the right thing when HAS_DECL_ASSEMBLER_NAME_P() is false (it ICEs). Yea, I found the same mis-mash of bits that didn't look directly usable for the problem you're tackling. What's odd is I would have sworn that we had code to do exactly what you wanted, but I wasn't able to find it, either as a distinct routine or open-coded. In the end, I added a new function, maybe_nonzero_address(), that calls symtab_node::nonzero_address(), and that I factored out of tree_single_nonzero_warnv_p() that I was then able to use in fold_comparison(). Sounds good. I've made a few other small adjustments to the patch to avoid one false positive, and a few test cases, and tweak the expected diagnostics now that Marek has fixed 70194. I've also wrote myself a small sed script to replace blocks of 8 spaces with tabs and ran the patch through it. I'll integrate it into my workflow so I hopefully don't have to worry about this ever again. I'll try to take a look at the updated patch shortly. It may still hit too much of the C++ front-end for me to be comfortable reviewing -- we'll see. jeff
Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression
On 03/17/2016 03:16 PM, Martin Sebor wrote:
gcc-67376.patch
PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
of array fails inside constant expression
PR c++/70170 - [6 regression] bogus not a constant expression error comparing
pointer to array to null
PR c++/70172 - incorrect reinterpret_cast from integer to pointer error
on invalid constexpr initialization
PR c++/60760 - arithmetic on null pointers should not be allowed in constant
expressions
PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds
array subscript
gcc/testsuite/ChangeLog:
2016-03-17 Martin Sebor
PR c++/67376
PR c++/70170
PR c++/70172
PR c++/60760
PR c++/70228
* g++.dg/cpp0x/constexpr-array-ptr10.C: New test.
* g++.dg/cpp0x/constexpr-array-ptr9.C: New test.
* g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic.
* g++.dg/cpp0x/constexpr-nullptr.C: Add test cases.
* g++.dg/cpp0x/constexpr-string.C: Same.
* g++.dg/cpp0x/constexpr-wstring2.C: Same.
* g++.dg/cpp0x/pr65398.C: Same.
* g++.dg/ext/constexpr-vla1.C: Same.
* g++.dg/ext/constexpr-vla2.C: Same.
* g++.dg/ext/constexpr-vla3.C: Same.
* g++.dg/ubsan/pr63956.C: Same.
gcc/cp/ChangeLog:
2016-03-17 Martin Sebor
PR c++/67376
PR c++/70170
PR c++/70172
PR c++/60760
PR c++/70228
* constexpr.c (cxx_eval_binary_expression): Add argument.
(cxx_eval_component_reference): Same.
(cxx_eval_constant_expression): Same.
(cxx_eval_indirect_ref): Same.
(cxx_eval_outermost_constant_expr): Same.
(diag_array_subscript): New function.
(cxx_eval_call_expression): Adjust.
(cxx_eval_conditional_expression): Same.
(cxx_eval_array_reference): Detect null pointers.
(cxx_eval_statement_list): Adjust.
gcc/ChangeLog:
2016-03-17 Martin Sebor
PR c++/67376
* fold-const.c (maybe_nonzero_address): New function.
(fold_comparison): Call it. Fold equality and relational
expressions involving null pointers.
(tree_single_nonzero_warnv_p): Call maybe_nonzero_address.
Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c (revision 234306)
+++ gcc/cp/constexpr.c (working copy)
@@ -1839,11 +1874,26 @@ cxx_eval_array_reference (const constexp
@@ -3300,10 +3357,21 @@ cxx_eval_constant_expression (const cons
+
+ if (TREE_CODE (t) == INTEGER_CST
+ && TREE_CODE (TREE_TYPE (t)) == POINTER_TYPE
+ && !integer_zerop (t))
+ {
+ if (!ctx->quiet)
+ error ("null pointer arithmetic in %qE", t);
+ if (nullptr_p)
+ *nullptr_p = true;
+ }
Something looks odd here.
You're testing !integer_zerop, so in T is going to be non-NULL, but you
mentioned null pointer arithmetic in the error message. Am I missing
something here?
@@ -3738,15 +3812,32 @@ cxx_eval_constant_expression (const cons
Index: gcc/fold-const.c
@@ -8639,6 +8653,38 @@ fold_comparison (location_t loc, enum tr
base1 = build_fold_addr_expr_loc (loc, base1);
return fold_build2_loc (loc, code, type, base0, base1);
}
+
+ /* Comparison between an ordinary (non-weak) symbol and a null
+pointer can be eliminated since such sybols must have a non
+null address. */
+ else if (DECL_P (base0)
+ && maybe_nonzero_address (base0) > 0
+ // && (!HAS_DECL_ASSEMBLER_NAME_P (base0) || !DECL_WEAK (base0))
Please remove the commented out line.
+ /* Avoid folding references to struct members at offset 0 to
+ prevent tests like '&ptr->firstmember == 0' from getting
+ eliminated. When ptr is null, although the -> expression
+ is strictly speaking invalid, GCC retains it as a matter
+ of QoI. See PR c/44555. */
+ && (TREE_CODE (op0) != ADDR_EXPR
+ || TREE_CODE (TREE_OPERAND (op0, 0)) != COMPONENT_REF
+ || compare_tree_int (DECL_FIELD_OFFSET ((TREE_OPERAND
+ (TREE_OPERAND (op0, 0), 1))), 0))
+ && TREE_CODE (arg1) == INTEGER_CST
+ && compare_tree_int (arg1, 0) == 0)
+ {
+ switch (code)
+ {
+ case GE_EXPR:
+ case EQ_EXPR:
+ case LE_EXPR:
+ return boolean_false_node;
+ case GT_EXPR:
+ case LT_EXPR:
+ case NE_EXPR:
+ return boolean_true_node;
+ default: gcc_unreachable ();
Can you put the gcc_unreachable on a new line? I know there's a few
cases in the sources where it's on the default: line, but the vast
majority have it on its own line.
[Patch, fortran] PR68566 ICE on using unusable array in reshape (double free or corruption)
Hi,
the above ICE is fixed by the following simple/trivial fix:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 234170)
+++ gcc/fortran/simplify.c (working copy)
@@ -5163,6 +5163,9 @@
|| !is_constant_array_expr (order_exp))
return NULL;
+ if (source->shape == NULL)
+return NULL;
+
/* Proceed with simplification, unpacking the array. */
mpz_init (index);
Proposed testcase:
Index: gcc/testsuite/gfortran.dg/pr68566.f90
===
--- gcc/testsuite/gfortran.dg/pr68566.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/pr68566.f90 (revision 0)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/68566 - ICE on using unusable array in reshape
+! Testcase by Gerhard Steinmetz
+
+program p
+ integer, parameter :: a(:) = 1 ! { dg-error "or of deferred
shape" }
+ integer, parameter :: b(2,2) = reshape([a], [2,2])
+end
Regtested with no new failures on i686-pc-linux-gnu.
Whoever wants to take it...
Cheers,
Harald
Re: [PATCH V3]PR other/70268: map one directory name (old) to another (new) in __FILE__
On 03/18/2016 04:05 PM, Hongxu Jia wrote: Please explain why you first alloca() and then strdup the result instead of XNEWVEC BTW, I just refer the implement of -fdebug-prefix-map: In gcc/final.c const char * remap_debug_filename (const char *filename) //Hongxu 1. alloca - allocate memory that is automatically freed when the function remap_file_filename returns 2. XNEW - allocate memory for struct file_prefix_map 3. xstrdup - duplicate a string //Hongxu Thanks,
Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class
On 03/16/2016 08:38 AM, H.J. Lu wrote: FAIL: g++.dg/abi/pr60336-1.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-5.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-6.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-7.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-9.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr68355.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx17integral_constantIbLb1EE These pass for me on x86_64, but I do see calls with -m32. They are expected since get_ref_base_and_extent needs to be changed to set bitsize to 0 for empty types so that when ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to get 0 as the maximum size on empty type. Otherwise, find_tail_calls won't perform tail call optimization for functions with empty type parameters. That isn't why the optimization isn't happening in pr68355 with -m32; the .optimized dump has xxx (D.2289); [tail call] Rather, the failure seems to happen in load_register_parameter, at /* Check for overlap with already clobbered argument area, providing that this has non-zero size. */ if (is_sibcall && (size == 0 || mem_overlaps_already_clobbered_arg_p (XEXP (args[i].value, 0), size))) *sibcall_failure = 1; The code seems to contradict the comment, and seems to have been broken by r162402. Applying this additional patch fixes those tests. commit b9e170023d97cef94f9b88ded1dfd3b4cf993294 Author: Jason Merrill Date: Wed Mar 16 12:57:37 2016 -0400 * calls.c (load_register_parameters): Fix zero size sibcall logic. diff --git a/gcc/calls.c b/gcc/calls.c index 7b28f43..6415e08 100644 --- a/gcc/calls.c +++ b/gcc/calls.c @@ -2083,9 +2083,9 @@ load_register_parameters (struct arg_data *args, int num_actuals, /* Check for overlap with already clobbered argument area, providing that this has non-zero size. */ if (is_sibcall - && (size == 0 - || mem_overlaps_already_clobbered_arg_p - (XEXP (args[i].value, 0), size))) + && size != 0 + && (mem_overlaps_already_clobbered_arg_p + (XEXP (args[i].value, 0), size))) *sibcall_failure = 1; if (size % UNITS_PER_WORD == 0
Re: [PATCH, rs6000] Add support for xxpermr and vpermr instructions
On Thu, Mar 17, 2016 at 2:58 PM, Kelvin Nilsen wrote: > > This patch adds support for two new Power9 instructions, xxpermr and vpermr, > providing more efficient vector permutation operations on > little-endian configurations. These new instructions are described in > the Power ISA 3.0 document. Selection of the new instructions is > conditioned upon TARGET_P9_VECTOR and !VECTOR_ELT_ORDER_BIG. > > The patch has bootstrapped and tested on powerpc64le-unknown-linux-gnu > and powerpc64-unknown-linux-gnu with no regressions. Is this ok for GCC 7 > when stage 1 opens? > > (A previous version of this patch was distributed and approved, but further > experience with testing of P9 fusion instructions revealed a problem with > that particular code expansion. So this new revision of the patch omits the > fusion instruction generation pattern.) > > Thanks. > > gcc/testsuite/ChangeLog: > > 2016-03-17 Kelvin Nilsen > > * gcc.target/powerpc/p9-permute.c: Generalize test to run on > big-endian Power9 in addition to little-endian Power9. > * gcc.target/powerpc/p9-vpermr.c: New test. > > > gcc/ChangeLog: > > 2016-03-17 Kelvin Nilsen > > * config/rs6000/altivec.md: (UNSPEC_VPERMR): New unspec > constant. > (*altivecvpermr__internal): New insn. > * config/rs6000/rs6000.c (rs6000_expand_vector_set): If > !BYTES_BIG_ENDIAN and TARGET_P9_VECTOR, expand using template > that translates into new xxpermr or vpermr instructions. > (altivec_expand_vec_perm_le): if TARGET_P9_VECTOR, expand using > template that translates into new xxpermr or vpermr > instructions. This is okay for GCC 7. Thanks, David
Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes
On 03/17/2016 02:02 PM, Jeff Law wrote: On 03/17/2016 12:23 PM, Bernd Schmidt wrote: On 03/17/2016 06:37 PM, Jeff Law wrote: + bitmap seen_insns; + seen_insns = BITMAP_ALLOC (NULL); You could save an allocation here by making this a bitmap_head and using bitmap_initialize. + bitmap_set_bit (seen_insns, INSN_UID (insn)); + if (! INSN_P (insn)) continue; @@ -3646,7 +3656,8 @@ update_equiv_regs (void) && ! find_reg_note (XEXP (reg_equiv[regno].init_insns, 0), REG_EQUIV, NULL_RTX) && ! contains_replace_regs (XEXP (dest, 0)) - && ! pdx_subregs[regno]) + && ! pdx_subregs[regno] + && ! bitmap_bit_p (seen_insns, INSN_UID (insn))) This looks odd to me. Isn't this condition always false? Did you want to test the init_insn? And thinking about this a bit more, I can't see how this code was correct to begin with -- a linear scan of the insns between init_insn and insn does not necessarily correspond to actual control flow during execution. We could have a jump between those points that targets a label that is outside those points. At that target label we might load from DEST. I guess the fact that the reg is only used in a single basic block is probably what saves us here. I do need to check that if the set of a reg is in one block and uses are in another that we don't set REG_BASIC_BLOCK. jeff
Emit square root using the Newton series
2016-03-16 Evandro Menezes
Wilco Dijkstra
gcc/
* config/aarch64/aarch64-tuning-flags.def
(AARCH64_EXTRA_TUNE_APPROX_SQRT_{SF,DF}): New tuning macros.
* config/aarch64/aarch64-protos.h
(aarch64_emit_approx_rsqrt): Replace with
"aarch64_emit_approx_sqrt".
(AARCH64_EXTRA_TUNE_APPROX_SQRT): New macro.
* config/aarch64/aarch64.c
(exynosm1_tunings): Use the new macro.
(aarch64_emit_approx_sqrt): Define new function.
* config/aarch64/aarch64.md
(rsqrt2): Use new function instead.
(sqrt2): New expansion and insn definitions.
* config/aarch64/aarch64-simd.md: Likewise.
* config/aarch64/aarch64.opt
(mlow-precision-recip-sqrt): Expand option description.
* doc/invoke.texi (mlow-precision-recip-sqrt): Likewise.
This patch refactors the function to emit the reciprocal square root
approximation to also emit the square root approximation.
Feedback is welcome.
Thank you,
--
Evandro Menezes
>From 8d00622b90fa414df605011446ac058efe867cf6 Mon Sep 17 00:00:00 2001
From: Evandro Menezes
Date: Thu, 17 Mar 2016 17:39:55 -0500
Subject: [PATCH] Emit square root using the Newton series
2016-03-17 Evandro Menezes
Wilco Dijkstra
gcc/
* config/aarch64/aarch64-tuning-flags.def
(AARCH64_EXTRA_TUNE_APPROX_SQRT_{SF,DF}): New tuning macros.
* config/aarch64/aarch64-protos.h
(aarch64_emit_approx_rsqrt): Replace with "aarch64_emit_approx_sqrt".
(AARCH64_EXTRA_TUNE_APPROX_SQRT): New macro.
* config/aarch64/aarch64.c
(exynosm1_tunings): Use the new macro.
(aarch64_emit_approx_sqrt): Define new function.
* config/aarch64/aarch64.md
(rsqrt2): Use new function instead.
(sqrt2): New expansion and insn definitions.
* config/aarch64/aarch64-simd.md: Likewise.
* config/aarch64/aarch64.opt
(mlow-precision-recip-sqrt): Expand option description.
* doc/invoke.texi (mlow-precision-recip-sqrt): Likewise.
---
gcc/config/aarch64/aarch64-protos.h | 5 +-
gcc/config/aarch64/aarch64-simd.md | 27 +++-
gcc/config/aarch64/aarch64-tuning-flags.def | 3 +-
gcc/config/aarch64/aarch64.c| 97 +++--
gcc/config/aarch64/aarch64.md | 25 +++-
gcc/config/aarch64/aarch64.opt | 4 +-
gcc/doc/invoke.texi | 9 +--
7 files changed, 139 insertions(+), 31 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index dced209..3f3ae1c 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -263,6 +263,9 @@ enum aarch64_extra_tuning_flags
};
#undef AARCH64_EXTRA_TUNING_OPTION
+#define AARCH64_EXTRA_TUNE_APPROX_SQRT \
+ (AARCH64_EXTRA_TUNE_APPROX_SQRT_DF | AARCH64_EXTRA_TUNE_APPROX_SQRT_SF)
+
extern struct tune_params aarch64_tune_params;
HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned, unsigned);
@@ -361,7 +364,7 @@ void aarch64_register_pragmas (void);
void aarch64_relayout_simd_types (void);
void aarch64_reset_previous_fndecl (void);
void aarch64_save_restore_target_globals (tree);
-void aarch64_emit_approx_rsqrt (rtx, rtx);
+void aarch64_emit_approx_sqrt (rtx, rtx, bool);
/* Initialize builtins for SIMD intrinsics. */
void init_aarch64_simd_builtins (void);
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index bd73bce..31191bb 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -405,7 +405,7 @@
UNSPEC_RSQRT))]
"TARGET_SIMD"
{
- aarch64_emit_approx_rsqrt (operands[0], operands[1]);
+ aarch64_emit_approx_sqrt (operands[0], operands[1], true);
DONE;
})
@@ -4307,7 +4307,30 @@
;; sqrt
-(define_insn "sqrt2"
+(define_expand "sqrt2"
+ [(set (match_operand:VDQF 0 "register_operand")
+ (sqrt:VDQF (match_operand:VDQF 1 "register_operand")))]
+ "TARGET_SIMD"
+{
+ machine_mode mode = GET_MODE_INNER (GET_MODE (operands[1]));
+
+ if (flag_finite_math_only
+ && !flag_trapping_math
+ && flag_unsafe_math_optimizations
+ && !optimize_function_for_size_p (cfun)
+ && ((mode == SFmode
+ && (aarch64_tune_params.extra_tuning_flags
+ & AARCH64_EXTRA_TUNE_APPROX_SQRT_SF))
+ || (mode == DFmode
+ && (aarch64_tune_params.extra_tuning_flags
+ & AARCH64_EXTRA_TUNE_APPROX_SQRT_DF
+{
+ aarch64_emit_approx_sqrt (operands[0], operands[1], false);
+ DONE;
+}
+})
+
+(define_insn "*sqrt2"
[(set (match_operand:VDQF 0 "register_operand" "=w")
(sqrt:VDQF (match_operand:VDQF 1 "register_operand" "w")))]
"TARGET_SIMD"
diff --git a/gcc/config/aarch64/aarch64-tuning-flags.def b/gcc/config/aarch64/aarch64-tuning-flags.def
index 7e45a0c..725a79c 100644
--- a/gcc/config/aarch64/aarch64-tuning-flags.def
+++ b/gcc/config/aarch64/aarch64-tuning-flags.def
@@ -30,4 +30,5 @@
AARCH64_EXTRA_
Re: [RFC] Getting LTO incremental linking work
On Wed, Nov 25, 2015 at 12:59 AM, Jan Hubicka wrote:
> Hi,
> PR 67548 is about LTO not supporting incremental linking. I never really
> considered our current incremental linking very useful, because it triggers
> code generation at the incremental link time basically nullifying any
> benefits of whole program optimization and in fact I think it is harmful,
> because it sort of works and w/o any warning produce not very optimized code.
>
> --- gcc/lto/lto-lang.c (revision 230847)
> +++ gcc/lto/lto-lang.c (working copy)
> @@ -819,6 +819,56 @@ lto_post_options (const char **pfilename
>if (flag_wpa)
> flag_generate_lto = 1;
>
> + /* Initialize the codegen flags according to the output type. */
> + switch (flag_lto_linker_output)
> +{
> +case LTO_LINKER_OUTPUT_REL: /* .o: incremental link producing LTO IL */
> + /* Configure compiler same way as normal frontend would do with -flto:
> +this way we read the trees (declarations & types), symbol table,
> +optimization summaries and link them. Subsequently we output new LTO
> +file. */
> + flag_lto = "";
> + flag_incremental_link = 2;
> + flag_whole_program = 0;
> + flag_wpa = 0;
> + flag_generate_lto = 1;
> + /* It would be cool to produce .o file directly, but our current
> +simple objects does not contain the lto symbol markers. Go the slow
> +way through the asm file. */
> + lang_hooks.lto.begin_section = lhd_begin_section;
> + lang_hooks.lto.append_data = lhd_append_data;
> + lang_hooks.lto.end_section = lhd_end_section;
> + if (flag_ltrans)
> + error ("-flinker-output=rel and -fltrans are mutually exclussive");
> + break;
> +
> +case LTO_LINKER_OUTPUT_NOLTOREL: /* .o: incremental link producing asm
> */
> + flag_whole_program = 0;
> + flag_incremental_link = 1;
> + break;
> +
> +case LTO_LINKER_OUTPUT_DYN: /* .so: PID library */
> + /* On some targets, like i386 it makes sense to build PIC library
> wihout
> +-fpic for performance reasons. So no need to adjust flags. */
> + break;
> +
> +case LTO_LINKER_OUTPUT_PIE: /* PIE binary */
> + /* If -fPIC or -fPIE was used at compile time, be sure that
> + flag_pie is 2. */
> + if (!flag_pie && flag_pic)
> + flag_pie = flag_pic;
> + flag_pic = 0;
This is wrong since PIE implies PIC.
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258
> + break;
> +
>
Re: [PATCH] c++/65579 - set readonly bit on static constexpr members of templates
On 03/09/2016 05:09 PM, Martin Sebor wrote: While going through constexpr bugs looking for background on one I'm currently working on I came across bug 65579 - [C++11] gcc requires definition of a static constexpr member even though it is not odr-used. The bug points out that GCC (sometimes) emits references to static constexpr data members of class templates even when they aren't odr-used. (A more detailed analysis of why this happens is in my comment #1 on the bug.) This should have been fixed up in complete_vars; why didn't it work? Jason
[committed patch] Sync top-level configure.ac with binutils-gdb
I'm committing this patch to sync the top-level configure with binutils-gdb.
-cary
2016-03-17 Cary Coutant
* configure.ac: Add mips and s390 to the gold target check.
* configure: Regenerate.
Index: configure
===
--- configure (revision 234307)
+++ configure (working copy)
@@ -2973,7 +2973,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
Index: configure.ac
===
--- configure.ac(revision 234307)
+++ configure.ac(working copy)
@@ -351,7 +351,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
Re: [PATCH, PR70183] Propagate dump flags in pass_manager::register_pass
On Wed, Mar 16, 2016 at 12:26 PM, Tom de Vries wrote: > Hi, > > atm dumpfile vzeroupper is not influenced by the flags in > -fdump-rtl-all-flags. > > The patch fixes this by copying the flags in pass_manager::register_pass. > > OK for stage1 if bootstrap and reg-test succeeds? Ok. Richard. > Thanks, > - Tom
Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class
On Wed, Mar 16, 2016 at 7:33 AM, Jason Merrill wrote: > On 03/16/2016 07:55 AM, H.J. Lu wrote: >> >> On Tue, Mar 15, 2016 at 7:51 PM, Jason Merrill wrote: >>> >>> On 03/15/2016 08:25 PM, Joseph Myers wrote: On Tue, 15 Mar 2016, H.J. Lu wrote: > On Tue, Mar 15, 2016 at 3:34 PM, Joseph Myers > wrote: >> >> >> On Tue, 15 Mar 2016, H.J. Lu wrote: >> >>> On Tue, Mar 15, 2016 at 2:39 PM, Joseph Myers >>> >>> wrote: I'm not sure if the zero-size arrays (a GNU extension) are considered to make a struct non-empty, but in any case I think the tests should cover such arrays as elements of structs. >>> >>> >>> >>> There are couple tests for structs with members of array >>> of empty types. testsuite/g++.dg/abi/empty14.h has >> >> >> >> My concern is the other way round - structs with elements such as >> "int a[0];", an array [0] of a nonempty type. My reading of the >> subobject >> definition is that such an array should not cause the struct to be >> considered nonempty (it doesn't result in any int subobjects). > > > > This is a test for struct with zero-size array, which isn't treated > as empty type. C++ and C are compatible in its passing. Where is the current definition of empty types you're proposing for use in GCC? Is the behavior of this case clear from that definition? >>> >>> >>> >>> "An empty type is a type where it and all of its subobjects (recursively) >>> are of structure, union, or array type. No memory slot nor register >>> should >>> be used to pass or return an object of empty type." >>> >>> It seems to me that such a struct should be considered an empty type >>> under >>> this definition, since a zero-length array has no subobjects. >> >> >> Since zero-size array is GCC extension, we can change it. Do we >> want to change its passing for C? > > > I would think so; it seems to follow clearly from this definition. I have > trouble imagining that anyone would ever pass an object containing a > zero-length array by value, so it shouldn't matter much either way, but I > consistency is good. > This requires change in both C and C++ frontends. -- H.J.
Re: [PATCH] Fix 70199
On 03/16/2016 02:40 AM, Richard Biener wrote:
I like patch 2 more - btw, you need to add has_forced_label_in_static streaming
to lto-streamer-{in,out}.c, just look for has_nonlocal_label streaming. Also
has_label_address_in_static_1 is now unused and should be removed.
I'd already found the latter with a full bootstrap, but thanks for the catch
wrt the former. I've now committed the following that addresses both.
r~
PR middle-end/70199
* function.h (struct function): Add has_forced_label_in_static.
* gimplify.c (force_labels_r): Set it.
* lto-streamer-in.c (input_struct_function_base): Read it.
* lto-streamer-out.c (output_struct_function_base): Write it.
* tree-inline.c (has_label_address_in_static_1): Remove.
(copy_forbidden): Remove fndecl parameter; test
has_forced_label_in_static.
(inline_forbidden_p): Update call to copy_forbidden.
(tree_versionable_function_p): Likewise.
* ipa-chkp.c (chkp_instrumentable_p): Likewise.
(chkp_versioning): Likewise.
* tree-inline.h (copy_forbidden): Update decl.
testsuite/
* gcc.c-torture/compile/pr70199.c: New.
diff --git a/gcc/function.h b/gcc/function.h
index c4368cd..501ef68 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -328,6 +328,10 @@ struct GTY(()) function {
from nested functions. */
unsigned int has_nonlocal_label : 1;
+ /* Nonzero if function being compiled has a forced label
+ placed into static storage. */
+ unsigned int has_forced_label_in_static : 1;
+
/* Nonzero if we've set cannot_be_copied_reason. I.e. if
(cannot_be_copied_set && !cannot_be_copied_reason), the function
can in fact be copied. */
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 692d168..84ce46e 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1414,7 +1414,10 @@ force_labels_r (tree *tp, int *walk_subtrees, void *data
ATTRIBUTE_UNUSED)
if (TYPE_P (*tp))
*walk_subtrees = 0;
if (TREE_CODE (*tp) == LABEL_DECL)
-FORCED_LABEL (*tp) = 1;
+{
+ FORCED_LABEL (*tp) = 1;
+ cfun->has_forced_label_in_static = 1;
+}
return NULL_TREE;
}
diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index 4a6b43e..5f5df64 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -470,7 +470,7 @@ chkp_instrumentable_p (tree fndecl)
return (!lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
&& (!flag_chkp_instrument_marked_only
|| lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES (fndecl)))
- && (!fn || !copy_forbidden (fn, fndecl)));
+ && (!fn || !copy_forbidden (fn)));
}
/* Return clone created for instrumentation of NODE or NULL. */
@@ -644,22 +644,22 @@ chkp_versioning (void)
FOR_EACH_DEFINED_FUNCTION (node)
{
+ tree decl = node->decl;
if (!node->instrumentation_clone
&& !node->instrumented_version
&& !node->alias
&& !node->thunk.thunk_p
- && (!DECL_BUILT_IN (node->decl)
- || (DECL_BUILT_IN_CLASS (node->decl) == BUILT_IN_NORMAL
- && DECL_FUNCTION_CODE (node->decl) < BEGIN_CHKP_BUILTINS)))
+ && (!DECL_BUILT_IN (decl)
+ || (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (decl) < BEGIN_CHKP_BUILTINS)))
{
- if (chkp_instrumentable_p (node->decl))
- chkp_maybe_create_clone (node->decl);
- else if ((reason = copy_forbidden (DECL_STRUCT_FUNCTION (node->decl),
-node->decl)))
+ if (chkp_instrumentable_p (decl))
+ chkp_maybe_create_clone (decl);
+ else if ((reason = copy_forbidden (DECL_STRUCT_FUNCTION (decl
{
- if (warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wchkp,
+ if (warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wchkp,
"function cannot be instrumented"))
- inform (DECL_SOURCE_LOCATION (node->decl), reason, node->decl);
+ inform (DECL_SOURCE_LOCATION (decl), reason, decl);
}
}
}
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 48a1c86..dd48777 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1008,6 +1008,7 @@ input_struct_function_base (struct function *fn, struct
data_in *data_in,
fn->after_inlining = bp_unpack_value (&bp, 1);
fn->stdarg = bp_unpack_value (&bp, 1);
fn->has_nonlocal_label = bp_unpack_value (&bp, 1);
+ fn->has_forced_label_in_static = bp_unpack_value (&bp, 1);
fn->calls_alloca = bp_unpack_value (&bp, 1);
fn->calls_setjmp = bp_unpack_value (&bp, 1);
fn->has_force_vectorize_loops = bp_unpack_value (&bp, 1);
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 997a28b..6703d41 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2014,6 +2014,7 @@ output_struct_function_base (struct output_block *o
Re: [PATCH] PR c/70281: C FE: fix uninitialized range for __builtin_types_compatible_p
On 03/18/2016 10:25 AM, David Malcolm wrote: PR c/70281 reports another case where Valgrind identified an uninitialized src_range in a c_expr in the C frontend, this time in the parsing of __builtin_types_compatible_p. For gcc 7 I hope to fix this more robustly (via poisoning the values in a c_expr ctor), but for now, this patch fixes the specific issue found. Successfully bootstrapped on x86_64-pc-linux-gnu; adds 7 PASS results to gcc.sum. OK for trunk? gcc/c/ChangeLog: PR c/70281 * c-parser.c (c_parser_postfix_expression): Set the source range for uses of "__builtin_types_compatible_p". gcc/testsuite/ChangeLog: PR c/70281 * gcc.dg/plugin/diagnostic-test-expressions-1.c (test_builtin_types_compatible_p): New test function. * gcc.dg/pr70281.c: New test case. OK jeff
[PATCH, aarch64] Fix target/70120
With -g, and a code section that ends unaligned, the assembler complains of
"unaligned opcodes detected". Except there are no such unaligned opcodes, nor
dwarf2 code ranges covering the end of the section, which arguably makes this
an assembler bug. However, it's reasonably easy to work around in the
compiler, which saves having to bump the required binutils version.
Tested on aarch64-linux.
r~
PR target/70120
* varasm.c (for_each_section): New.
* varasm.h (for_each_section): Declare.
* config/aarch64/aarch64.c (aarch64_align_code_section): New.
(aarch64_asm_file_end): New.
(TARGET_ASM_FILE_END): Redefine.
testsuite/
* gcc.target/aarch64/pr70120-1.c: New.
* gcc.target/aarch64/pr70120-2.c: New.
* gcc.target/aarch64/pr70120-3.c: New.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index cf1239d..cca9bd9 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -13989,6 +13989,39 @@ aarch64_optab_supported_p (int op, machine_mode,
machine_mode,
}
}
+/* A subroutine of aarch64_asm_file_end. Callback to align the
+ given section if it contains code. */
+
+static void
+aarch64_align_code_section (section *s)
+{
+ if (s->common.flags & SECTION_CODE)
+{
+ switch_to_section (s);
+ ASM_OUTPUT_ALIGN (asm_out_file, 2);
+}
+}
+
+/* Implement the TARGET_ASM_FILE_END hook. */
+
+static void
+aarch64_asm_file_end (void)
+{
+ /* When using per-function literal pools, we must ensure that any code
+ section is aligned to the minimal instruction length, lest we get
+ errors from the assembler re "unaligned instructions". */
+ if (aarch64_can_use_per_function_literal_pools_p ())
+for_each_section (aarch64_align_code_section);
+
+ /* If a subtarget has already defined this hook, call it. */
+#ifdef TARGET_ASM_FILE_END
+ TARGET_ASM_FILE_END ();
+#endif
+}
+
+#undef TARGET_ASM_FILE_END
+#define TARGET_ASM_FILE_END aarch64_asm_file_end
+
#undef TARGET_ADDRESS_COST
#define TARGET_ADDRESS_COST aarch64_address_cost
diff --git a/gcc/testsuite/gcc.target/aarch64/pr70120-1.c
b/gcc/testsuite/gcc.target/aarch64/pr70120-1.c
new file mode 100644
index 000..31a5e94
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr70120-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -fschedule-insns -mno-pc-relative-literal-loads -g" } */
+
+typedef short v32u16 __attribute__ ((vector_size (32)));
+typedef int v32u32 __attribute__ ((vector_size (32)));
+typedef long v32u64 __attribute__ ((vector_size (32)));
+typedef __int128 u128;
+typedef __int128 v32u128 __attribute__ ((vector_size (32)));
+
+int
+foo(int u16_0, int u32_0, int u64_0, u128 u128_0, int u16_1, int u32_1, int
u64_1, u128 u128_1, v32u16 v32u16_0, v32u32 v32u32_0, v32u64 v32u64_0, v32u128
v32u128_0, v32u16 v32u16_1, v32u32 v32u32_1, v32u64 v32u64_1, v32u128 v32u128_1)
+{
+ v32u32_1 ^= (v32u32) ~ v32u64_0;
+ v32u32_1 %= (v32u32) - v32u16_1 | 1;
+ v32u16_1 -= (v32u16) v32u16_1;
+ v32u64_0 *= (v32u64){~ u128_0, v32u16_1[5], v32u16_0[15], v32u32_1[4]};
+ v32u16_0 /= (v32u16){0x574c, ~u128_1, v32u128_1[0], u64_1, v32u64_0[1],
v32u64_1[2], 0, 0x8ce6, u128_1, 0x5e69} |1;
+ return v32u16_0[0] + v32u16_0[6] + v32u16_0[8] + v32u16_0[9] + v32u32_0[0] +
v32u32_0[1] + v32u32_0[2] + v32u32_0[3] + v32u32_0[4] + v32u32_0[6] +
v32u64_0[0] + v32u64_0[2] + v32u64_0[3] + v32u128_0[0] + v32u128_0[1] +
v32u32_1[0] + v32u32_1[2] + v32u64_1[2] + v32u64_1[3] + v32u128_1[1];
+}
diff --git a/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
b/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
new file mode 100644
index 000..0110224
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -freorder-functions -g3 -mcmodel=large" } */
+
+typedef short v32u16 __attribute__ ((vector_size (32)));
+typedef int v32u32 __attribute__ ((vector_size (32)));
+typedef long v32u64 __attribute__ ((vector_size (32)));
+typedef __int128 u128;
+typedef __int128 v32u128 __attribute__ ((vector_size (32)));
+
+int
+foo (int u16_0, int u32_0, int u64_0, u128 u128_0, int u16_1, int u32_1,
v32u16 v32u16_0, v32u32 v32u32_0, v32u64 v32u64_0, v32u128 v32u128_0, v32u16
v32u16_1, v32u32 v32u32_1, v32u64 v32u64_1, v32u128 v32u128_1)
+{
+ u128_0 <<= 0x6c;
+ v32u16_1 %= (v32u16) { 1, 64, 0xf294, 0, u32_1, v32u32_1[6], ~u128_0,
0x2912, v32u32_0[2]} | 1;
+ v32u16_0 ^= (v32u16){-v32u16_1[11], -u32_1, 64, ~u128_0, 0, 1, 64, ~u64_0,
0};
+ return u16_0 + u32_0 + u16_1 + v32u16_0[0] + v32u32_0[1] + v32u32_0[2] +
v32u32_0[4] + v32u32_0[6] + v32u64_0[0] + v32u64_0[1] + v32u64_0[2] +
v32u64_0[3] + v32u128_0[0] + v32u128_0[1] + v32u16_1[0] + v32u32_1[7] +
v32u64_1[0] + v32u64_1[1] + v32u64_1[2] + v32u64_1[3] + v32u128_1[0] +
v32u128_1[1];
+}
diff --git a/gcc/testsuite/gcc.target/aarch64/pr70120-3.c
b/gcc/testsuite/gcc.target/aarch64/pr70120-3.c
new file mode 100644
Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245)
On 03/16/2016 01:22 PM, Jakub Jelinek wrote: So, this is what we've converged to on IRC and passed bootstrap/regtest on x86_64-linux and i686-linux. Is this ok for trunk? The explanation was a bit confusing at first, but I think this looks reasonable. The assert worries me, but triggering it would indicate a potential miscompilation, so I think it is preferrable to have it. Bernd
[PATCH] Fix PR c++/70205 (ICE on valid call to qualified static member function)
adjust_result_of_qualified_name_lookup() may erroneously clobber the
BASELINK_BINFO of its DECL argument if the BINFO_TYPE of DECL is an
ambiguous base of the qualifying scope that's used to refer to DECL.
But as the comment in the function suggests, this base ambiguity is not
necessarily a problem since DECL may later get resolved to a static
member function.
This patch makes updating the BASELINK_BINFO of DECL conditional on the
validity of the return value of the 2nd call to lookup_base as well as
on the 1st call. Not sure if we should still update BASELINK_ACCESS_BINFO
if the 2nd call fails, but I suppose it shouldn't hurt. I can't come up
with a test case where this would make a difference.
Bootstrap + regtest in progress on x86_64-pc-linux-gnu, also will test
against Boost, does this look OK to commit if testing succeeds?
gcc/cp/ChangeLog:
PR c++/70205
* search.c (adjust_result_of_qualified_name_lookup): Don't
update the BASELINK_BINFO of DECL if the second call
to lookup_base fails.
gcc/testsuite/ChangeLog:
PR c++/70205
* g++.dg/lookup/pr70205.C: New test.
---
gcc/cp/search.c | 4 +++-
gcc/testsuite/g++.dg/lookup/pr70205.C | 11 +++
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/lookup/pr70205.C
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 7924611..503e34b 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -1751,9 +1751,11 @@ adjust_result_of_qualified_name_lookup (tree decl,
if (base && base != error_mark_node)
{
BASELINK_ACCESS_BINFO (decl) = base;
- BASELINK_BINFO (decl)
+ tree decl_binfo
= lookup_base (base, BINFO_TYPE (BASELINK_BINFO (decl)),
ba_unique, NULL, tf_none);
+ if (decl_binfo && decl_binfo != error_mark_node)
+ BASELINK_BINFO (decl) = decl_binfo;
}
}
diff --git a/gcc/testsuite/g++.dg/lookup/pr70205.C
b/gcc/testsuite/g++.dg/lookup/pr70205.C
new file mode 100644
index 000..3bda7fb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/pr70205.C
@@ -0,0 +1,11 @@
+// PR c++/70205
+
+struct A
+{
+protected:
+ static void f ();
+};
+struct B : A { };
+struct C : A { };
+struct D : C, B { void a () { D::f (); } };
+struct E : D { void b () { D::f (); } };
--
2.8.0.rc1.12.gfce6d53
Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes
On 03/17/2016 12:23 PM, Bernd Schmidt wrote: On 03/17/2016 06:37 PM, Jeff Law wrote: + bitmap seen_insns; + seen_insns = BITMAP_ALLOC (NULL); You could save an allocation here by making this a bitmap_head and using bitmap_initialize. + bitmap_set_bit (seen_insns, INSN_UID (insn)); + if (! INSN_P (insn)) continue; @@ -3646,7 +3656,8 @@ update_equiv_regs (void) && ! find_reg_note (XEXP (reg_equiv[regno].init_insns, 0), REG_EQUIV, NULL_RTX) && ! contains_replace_regs (XEXP (dest, 0)) - && ! pdx_subregs[regno]) + && ! pdx_subregs[regno] + && ! bitmap_bit_p (seen_insns, INSN_UID (insn))) This looks odd to me. Isn't this condition always false? Did you want to test the init_insn? And thinking about this a bit more, I can't see how this code was correct to begin with -- a linear scan of the insns between init_insn and insn does not necessarily correspond to actual control flow during execution. We could have a jump between those points that targets a label that is outside those points. At that target label we might load from DEST. Hmm jeff
Re: Re: [PATCH][Testsuite] Add --param sra-max-scalarization-size-Ospeed to sra-12.c
On 21/10/15 16:59, Jeff Law wrote: > On 10/21/2015 09:52 AM, Alan Lawrence wrote: >> gcc.dg/tree-ssa/sra-12.c is skipped on a bunch of targets, including >> AArch64, >> because the default max-scalarization-size depends on MOVE_RATIO, and >> on those >> targets thus ends up being too small for SRA to optimize the testcase. >> Recently >> I noticed that the test has been failing for some time on ARM too. >> This patch >> fixes the test on ARM, AArch64, avr, and sh, and by extension I >> believe also on >> nds32, although I haven't managed to build a nds32 compiler to check. >> >> There is an argument that instead we should skip the test on ARM too; >> or rather, >> since at least ARM and AArch64 would like the test to pass, we should >> xfail it >> on those platforms until we have time to experiment with the >> threshold/param for >> SRA. I hope to do some more investigation on that front as part of (or >> followup >> to) PR/63679. >> >> Is this OK for trunk? >> >> Cheers, >> Alan >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/tree-ssa/sra-12.c: Enable test on all targets; add --param >> sra-max-scalarization-size-Ospeed. > OK. > jeff > OK to backport this to gcc-5-branch? Cheers, Andre
Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic
On Thu, Mar 17, 2016 at 8:09 AM, Bernd Schmidt wrote: > On 03/17/2016 04:06 PM, H.J. Lu wrote: >> >> This is the patch I am going to check in. > > > That still mentions darwin which I imagine might not be an exhaustive test. > We can add an effective target, something like ignore_pic_pie, and use it instead of *-*-darwin*. -- H.J.
Re: [RFA][PATCH][PR tree-optimization/64058] Improve and stabilize sorting of coalesce pairs
On 03/15/2016 08:22 AM, Richard Biener wrote: To work around the narrow API in the comparison function we have to either store additional data in each node or have them available in globals. The former would be horribly wasteful, the latter is just ugly. I choose the latter in the lazy evaluation of the conflicts version. Works for me. I'm going to take a look at Trevor's suggestion to use std::sort with a suitable class. That may ultimately be cleaner. As far as a testcase goes we want to scan the dumps for the actual coalesces being done. Might be a bit fragile though... I suspect that's going to be quite fragile and may have more target dependencies than we'd like (due to branch costing and such). Yes. Otherwise -ENOPATCH. Right. I haven't written the part to count the number of unique bits across two bitmaps yet as exported function from bitmap.[ch] yet. So no patch was included. Off to do that now :-) jeff
[Patch] [x86_64]: minor latency changes for znver1.md
Hi Uros, The below patch changes the latency values for fp type load reservations. It passes normal bootstrap and bootstrap with BOOT_CFLAGS="-O2 -g - march=znver1 -mno-clzero -mno-sha " on avx2 target. Also compiled and ran SPEC2006 with -march=znver1 and -Ofast . Ok for trunk? ChangeLog 2016-03-17 Venkataramanan Kumar * config/i386/znver1.md : Fix latency for FP/SSE/AVX load type reservations. ---snip--- diff --git a/gcc/config/i386/znver1.md b/gcc/config/i386/znver1.md index 1d28c05..7db0562 100644 --- a/gcc/config/i386/znver1.md +++ b/gcc/config/i386/znver1.md @@ -328,7 +328,7 @@ (eq_attr "type" "fcmov")) "znver1-vector,znver1-fvector") -(define_insn_reservation "znver1_fp_mov_direct_load" 5 +(define_insn_reservation "znver1_fp_mov_direct_load" 8 (and (eq_attr "cpu" "znver1") (and (eq_attr "znver1_decode" "direct") (and (eq_attr "type" "fmov") @@ -349,7 +349,7 @@ (eq_attr "memory" "none" "znver1-double,znver1-fp3") -(define_insn_reservation "znver1_fp_mov_double_load" 9 +(define_insn_reservation "znver1_fp_mov_double_load" 12 (and (eq_attr "cpu" "znver1") (and (eq_attr "znver1_decode" "double") (and (eq_attr "type" "fmov") @@ -386,7 +386,7 @@ (eq_attr "type" "fcmp" "znver1-double,znver1-fp0,znver1-fp2") -(define_insn_reservation "znver1_fp_fcmp_load" 6 +(define_insn_reservation "znver1_fp_fcmp_load" 9 (and (eq_attr "cpu" "znver1") (and (eq_attr "memory" "none") (and (eq_attr "znver1_decode" "double") @@ -400,13 +400,13 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp0*5") -(define_insn_reservation "znver1_fp_op_mul_load" 9 +(define_insn_reservation "znver1_fp_op_mul_load" 12 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "fop,fmul") (eq_attr "memory" "load"))) "znver1-direct,znver1-load,znver1-fp0*5") -(define_insn_reservation "znver1_fp_op_imul_load" 13 +(define_insn_reservation "znver1_fp_op_imul_load" 16 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "fop,fmul") (and (eq_attr "fp_int_src" "true") @@ -419,13 +419,13 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp3*15") -(define_insn_reservation "znver1_fp_op_div_load" 19 +(define_insn_reservation "znver1_fp_op_div_load" 22 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "fdiv") (eq_attr "memory" "load"))) "znver1-direct,znver1-load,znver1-fp3*15") -(define_insn_reservation "znver1_fp_op_idiv_load" 24 +(define_insn_reservation "znver1_fp_op_idiv_load" 27 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "fdiv") (and (eq_attr "fp_int_src" "true") @@ -444,7 +444,7 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp0|znver1-fp1|znver1-fp3") -(define_insn_reservation "znver1_mmx_add_load" 5 +(define_insn_reservation "znver1_mmx_add_load" 8 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "mmxadd") (eq_attr "memory" "load"))) @@ -456,7 +456,7 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp0|znver1-fp3") -(define_insn_reservation "znver1_mmx_cmp_load" 5 +(define_insn_reservation "znver1_mmx_cmp_load" 8 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "mmxcmp") (eq_attr "memory" "load"))) @@ -468,7 +468,7 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp1|znver1-fp2") -(define_insn_reservation "znver1_mmx_cvt_pck_shuf_load" 5 +(define_insn_reservation "znver1_mmx_cvt_pck_shuf_load" 8 (and (eq_attr "cpu" "znver1") (and (eq_attr "type" "mmxcvt,sseshuf,sseshuf1") (eq_attr "memory" "load"))) @@ -480,7 +480,7 @@ (eq_attr "memory" "none"))) "znver1-direct,znver1-fp2") -(define_insn_reservation "zn
C++ PATCH for c++/70139 (-fno-elide-constructors breaks regex)
The constexpr code for shortcutting trivial copy ctor/op= didn't get
updated for the C++14 constexpr implementation, where we need to
consider side effects.
For GCC 5.4 I'm just going to disable the shortcut.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a805189949e8ed36713d5eb78c283a5000566bf0
Author: Jason Merrill
Date: Fri Mar 18 14:57:58 2016 -0400
PR c++/70139
* constexpr.c (cxx_eval_call_expression): Fix trivial copy.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 5f97c9d..1f496b5 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1239,19 +1239,39 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t,
return t;
}
+ constexpr_ctx new_ctx = *ctx;
+ if (DECL_CONSTRUCTOR_P (fun) && !ctx->object
+ && TREE_CODE (t) == AGGR_INIT_EXPR)
+{
+ /* We want to have an initialization target for an AGGR_INIT_EXPR.
+ If we don't already have one in CTX, use the AGGR_INIT_EXPR_SLOT. */
+ new_ctx.object = AGGR_INIT_EXPR_SLOT (t);
+ tree ctor = new_ctx.ctor = build_constructor (DECL_CONTEXT (fun), NULL);
+ CONSTRUCTOR_NO_IMPLICIT_ZERO (ctor) = true;
+ ctx->values->put (new_ctx.object, ctor);
+ ctx = &new_ctx;
+}
+
/* Shortcut trivial constructor/op=. */
if (trivial_fn_p (fun))
{
+ tree init = NULL_TREE;
if (call_expr_nargs (t) == 2)
- {
- tree arg = convert_from_reference (get_nth_callarg (t, 1));
- return cxx_eval_constant_expression (ctx, arg,
- lval, non_constant_p,
- overflow_p);
- }
+ init = convert_from_reference (get_nth_callarg (t, 1));
else if (TREE_CODE (t) == AGGR_INIT_EXPR
&& AGGR_INIT_ZERO_FIRST (t))
- return build_zero_init (DECL_CONTEXT (fun), NULL_TREE, false);
+ init = build_zero_init (DECL_CONTEXT (fun), NULL_TREE, false);
+ if (init)
+ {
+ tree op = get_nth_callarg (t, 0);
+ if (is_dummy_object (op))
+ op = ctx->object;
+ else
+ op = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (op)), op);
+ tree set = build2 (MODIFY_EXPR, TREE_TYPE (op), op, init);
+ return cxx_eval_constant_expression (ctx, set, lval,
+ non_constant_p, overflow_p);
+ }
}
/* We can't defer instantiating the function any longer. */
@@ -1287,19 +1307,6 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t,
}
}
- constexpr_ctx new_ctx = *ctx;
- if (DECL_CONSTRUCTOR_P (fun) && !ctx->object
- && TREE_CODE (t) == AGGR_INIT_EXPR)
-{
- /* We want to have an initialization target for an AGGR_INIT_EXPR.
- If we don't already have one in CTX, use the AGGR_INIT_EXPR_SLOT. */
- new_ctx.object = AGGR_INIT_EXPR_SLOT (t);
- tree ctor = new_ctx.ctor = build_constructor (DECL_CONTEXT (fun), NULL);
- CONSTRUCTOR_NO_IMPLICIT_ZERO (ctor) = true;
- ctx->values->put (new_ctx.object, ctor);
- ctx = &new_ctx;
-}
-
bool non_constant_args = false;
cxx_bind_parameters_in_call (ctx, t, &new_call,
non_constant_p, overflow_p, &non_constant_args);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial1.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial1.C
new file mode 100644
index 000..f4b74a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial1.C
@@ -0,0 +1,20 @@
+// PR c++/70139
+// { dg-options "-fno-elide-constructors" }
+// { dg-do compile { target c++11 } }
+
+template
+struct A
+{
+ T a;
+ U b;
+ constexpr A () : a (), b () { }
+ constexpr A (const T &x, const U &y) : a (x), b (y) { }
+};
+struct B
+{
+ constexpr B (const bool x) : c (x) {}
+ constexpr bool operator!= (const B x) const { return c != x.c; }
+ bool c;
+};
+constexpr static A d[] = { { B (true), nullptr }, { B (false), nullptr } };
+static_assert (d[0].a != d[1].a, "");
Re: [PATCH][PR rtl-optimization/70024] Fix argument to CROSSING_JUMP_P
On 03/16/2016 11:37 AM, Andreas Schwab wrote: Jeff Law writes: PR rtl-optimization/70024 That's probably a typo. Already fixed. jeff
[gomp-nvptx 4/7] nvptx backend: re-enable line info generation
* config/nvptx/nvptx.c (nvptx_option_override): Remove custom handling
of debug info options.
---
gcc/ChangeLog.gomp-nvptx | 5 +
gcc/config/nvptx/nvptx.c | 9 -
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 81dd9a2..e69e0be 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -156,15 +156,6 @@ nvptx_option_override (void)
/* Assumes that it will see only hard registers. */
flag_var_tracking = 0;
- if (write_symbols == DBX_DEBUG)
-/* The stabs testcases want to know stabs isn't supported. */
-sorry ("stabs debug format not supported");
-
- /* Actually we don't have any debug format, but don't be
- unneccesarily noisy. */
- write_symbols = NO_DEBUG;
- debug_info_level = DINFO_LEVEL_NONE;
-
if (nvptx_optimize < 0)
nvptx_optimize = optimize > 0;
Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245, take 2)
On Thu, Mar 17, 2016 at 11:07:03PM +1030, Alan Modra wrote: > On Thu, Mar 17, 2016 at 12:16:58PM +0100, Jakub Jelinek wrote: > > the rs6000 backend for whatever strange reason I haven't understood > > really wants pointer equality instead of REGNO comparison (even when the > > modes match), one (reg:DI 12) should be replaced, another (reg:DI 12) > > should not. > > By the look of what you posted in the bugzilla, the pattern is the > parallel emitted by rs6000_emit_savres_rtx. In that parallel, the > stack memory locations for register saves are described relative to > whatever frame_reg_rtx is in use, which may be r12. > rs6000_frame_related wants to translate the frame_reg_rtx into stack > pointer plus offset for debug info. > > The parallel matches save_gpregs__r12 and similar in rs6000.md, > which emit a call to an out-of-line register save function. This > function actually takes r12 as a parameter, hence the (use (reg:P 12)) > in the pattern. > > rs6000_frame_related probably should just be replacing individual > SETs in the parallel using simplify_replace_rtx. Especially since > after calling replace_rtx, it already iterates over them to simplify. That was one thing, and another thing was during combiner, where it replaced just subset of the registers and left others in (e.g. with different mode). And on aarch64 trying to replace flags reg with CC_NZ mode when there is CC mode (or vice versa?). I bet for GCC 7 we want to analyze all uses of replace_rtx for what exactly we want. Jakub
Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc
On 23/10/15 12:31, Bernd Schmidt wrote:
> On 10/12/2015 11:58 AM, Ulrich Weigand wrote:
>>
>> Index: gcc/configure.ac
>> ===
>> --- gcc/configure.ac(revision 228530)
>> +++ gcc/configure.ac(working copy)
>> @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>> fi
>>
>> if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>> - if test "x$with_headers" != x; then
>> + if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>> target_header_dir=$with_headers
>> elif test "x$with_sysroot" = x; then
>>
>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>
>
> I'm missing the beginning of this conversation, but this looks like a
> reasonable change (avoiding target_header_dir=yes for --with-headers).
> So, approved.
>
>
> Bernd
>
Hi there,
I was wondering why this never made it to trunk. I am currently running
into an issue that this patch would fix.
Cheers,
Andre
[PATCH, PR tree-optimization/70252] Fix boolean vectors conversion
Hi,
Current widening and narrowing vectorization functions may work
incorrectly for scalar masks because we may have different boolean
vector types having the same mode. E.g. vec(4) and vec(8)
both have QImode. That means if we need to convert vec(4) into
vec(16) we may actually find QImode->HImode conversion optab
and try to use it which is incorrect because this optab entry is
used for vec(8) to vec(16) conversion.
I suppose the best fix for GCC 6 is to just catch and disable such
conversion by checking number of vetor elements. It doesn't disable
any vectorization because we don't have any conversion patterns
for vec(4) anyway.
It's not clear what to do for GCC 7 though to enable such conversions.
It looks like for AVX-512 we have three boolean vectors sharing the
same QImode: vec(2), vec(4) and vec(8). It means
we can't use optabs to check operations on these vectors even
using conversion optabs instead of direct ones. Can we use half/quarter
byte modes for such masks or something like that? Another option is to
handle their conversion separately with no optabs usage at all (target hooks?).
The patch was bootstrapped and regtested on x86_64-unknown-linux-gnu.
OK for trunk?
Thanks,
Ilya
--
gcc/
2016-03-17 Ilya Enkovich
PR tree-optimization/70252
* tree-vect-stmts.c (supportable_widening_operation): Check resulting
boolean vector has a proper number of elements.
(supportable_narrowing_operation): Likewise.
gcc/testsuite/
2016-03-17 Ilya Enkovich
PR tree-optimization/70252
* gcc.dg/pr70252.c: New test.
diff --git a/gcc/testsuite/gcc.dg/pr70252.c b/gcc/testsuite/gcc.dg/pr70252.c
new file mode 100644
index 000..209e691
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr70252.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+/* { dg-additional-options "-march=skylake-avx512" { target { i?86-*-*
x86_64-*-* } } } */
+
+extern unsigned char a [150];
+extern unsigned char b [150];
+extern unsigned char c [150];
+extern unsigned char d [150];
+extern unsigned char e [150];
+
+void foo () {
+ for (int i = 92; i <= 141; i += 2) {
+int tmp = (d [i] && b [i]) <= (a [i] > c [i]);
+e [i] = tmp >> b [i];
+ }
+}
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 06b1ab7..d12c062 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -8940,7 +8940,12 @@ supportable_widening_operation (enum tree_code code,
gimple *stmt,
if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype)
&& insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype))
-return true;
+ /* For scalar masks we may have different boolean
+vector types having the same QImode. Thus we
+add additional check for elements number. */
+return (!VECTOR_BOOLEAN_TYPE_P (vectype)
+ || (TYPE_VECTOR_SUBPARTS (vectype) / 2
+ == TYPE_VECTOR_SUBPARTS (wide_vectype)));
/* Check if it's a multi-step conversion that can be done using intermediate
types. */
@@ -8991,7 +8996,9 @@ supportable_widening_operation (enum tree_code code,
gimple *stmt,
if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype)
&& insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype))
- return true;
+ return (!VECTOR_BOOLEAN_TYPE_P (vectype)
+ || (TYPE_VECTOR_SUBPARTS (intermediate_type) / 2
+ == TYPE_VECTOR_SUBPARTS (wide_vectype)));
prev_type = intermediate_type;
prev_mode = intermediate_mode;
@@ -9075,7 +9082,12 @@ supportable_narrowing_operation (enum tree_code code,
*code1 = c1;
if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype))
-return true;
+/* For scalar masks we may have different boolean
+ vector types having the same QImode. Thus we
+ add additional check for elements number. */
+return (!VECTOR_BOOLEAN_TYPE_P (vectype)
+ || (TYPE_VECTOR_SUBPARTS (vectype) * 2
+ == TYPE_VECTOR_SUBPARTS (narrow_vectype)));
/* Check if it's a multi-step conversion that can be done using intermediate
types. */
@@ -9140,7 +9152,9 @@ supportable_narrowing_operation (enum tree_code code,
(*multi_step_cvt)++;
if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype))
- return true;
+ return (!VECTOR_BOOLEAN_TYPE_P (vectype)
+ || (TYPE_VECTOR_SUBPARTS (intermediate_type) * 2
+ == TYPE_VECTOR_SUBPARTS (narrow_vectype)));
prev_mode = intermediate_mode;
prev_type = intermediate_type;
Re: [PATCH] Change replace_rtx if from is a REG (PR target/70245, take 2)
On 03/17/2016 12:16 PM, Jakub Jelinek wrote: Thus, I've reverted the patch (kept the testcase), and after some discussions on IRC bootstrapped/regtested on x86_64-linux and i686-linux following version, which right now should change behavior just for the i?86 case and nothing else, so shouldn't break other targets. I believe at least the epiphany and sh peepholes that use replace_rtx will want similar treatment, but will leave testing of that to their maintainers. Ok for trunk? Ok. Bernd
Re: [gomp4.1] map clause parsing improvements
Hi!
On Mon, 19 Oct 2015 12:34:08 +0200, Jakub Jelinek wrote:
> On Mon, Oct 19, 2015 at 12:20:23PM +0200, Thomas Schwinge wrote:
> > > @@ -77,7 +79,21 @@ enum gomp_map_kind
> > > +/* OpenMP 4.1 alias for forced deallocation. */
> > > +GOMP_MAP_DELETE =GOMP_MAP_FORCE_DEALLOC,
> >
> > To avoid confusion about two different identifiers naming the same
> > functionality, I'd prefer to avoid such aliases ("GOMP_MAP_DELETE =
> > GOMP_MAP_FORCE_DEALLOC"), and instead just rename GOMP_MAP_FORCE_DEALLOC
> > to GOMP_MAP_DELETE, if that's the name you prefer.
>
> If you are ok with removing GOMP_MAP_FORCE_DEALLOC and just use
> GOMP_MAP_DELETE, that is ok by me, just post a patch.
That's simple enouch; OK to commit? (I'm also including the related
change, to rename the Fortran OMP_MAP_FORCE_DEALLOC to OMP_MAP_DELETE,
because I think that's what you'd do, once starting the OpenMP 4.5
Fortran front end work.)
commit d60e36a2a935a9319602221360b1a6abf282f434
Author: Thomas Schwinge
Date: Wed Mar 16 18:10:26 2016 +0100
Rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE
Also rename the Fortran OMP_MAP_FORCE_DEALLOC to OMP_MAP_DELETE.
include/
* gomp-constants.h (enum gomp_map_kind): Rename
GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE. Adjust all users.
gcc/fortran/
* gfortran.h (enum gfc_omp_map_op): Rename OMP_MAP_FORCE_DEALLOC
to OMP_MAP_DELETE. Adjust all users.
---
gcc/c/c-parser.c | 2 +-
gcc/cp/parser.c| 2 +-
gcc/fortran/gfortran.h | 2 +-
gcc/fortran/openmp.c | 2 +-
gcc/fortran/trans-openmp.c | 6 +++---
gcc/gimplify.c | 2 +-
gcc/omp-low.c | 2 +-
gcc/tree-pretty-print.c| 2 +-
include/gomp-constants.h | 6 ++
libgomp/oacc-parallel.c| 6 +++---
10 files changed, 15 insertions(+), 17 deletions(-)
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 60ec996..82d6eca 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -10715,7 +10715,7 @@ c_parser_oacc_data_clause (c_parser *parser,
pragma_omp_clause c_kind,
kind = GOMP_MAP_FORCE_ALLOC;
break;
case PRAGMA_OACC_CLAUSE_DELETE:
- kind = GOMP_MAP_FORCE_DEALLOC;
+ kind = GOMP_MAP_DELETE;
break;
case PRAGMA_OACC_CLAUSE_DEVICE:
kind = GOMP_MAP_FORCE_TO;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 62570d4..8ba4ffe 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -30086,7 +30086,7 @@ cp_parser_oacc_data_clause (cp_parser *parser,
pragma_omp_clause c_kind,
kind = GOMP_MAP_FORCE_ALLOC;
break;
case PRAGMA_OACC_CLAUSE_DELETE:
- kind = GOMP_MAP_FORCE_DEALLOC;
+ kind = GOMP_MAP_DELETE;
break;
case PRAGMA_OACC_CLAUSE_DEVICE:
kind = GOMP_MAP_FORCE_TO;
diff --git gcc/fortran/gfortran.h gcc/fortran/gfortran.h
index 33fffd8..a0fb5fd 100644
--- gcc/fortran/gfortran.h
+++ gcc/fortran/gfortran.h
@@ -1112,8 +1112,8 @@ enum gfc_omp_map_op
OMP_MAP_TO,
OMP_MAP_FROM,
OMP_MAP_TOFROM,
+ OMP_MAP_DELETE,
OMP_MAP_FORCE_ALLOC,
- OMP_MAP_FORCE_DEALLOC,
OMP_MAP_FORCE_TO,
OMP_MAP_FORCE_FROM,
OMP_MAP_FORCE_TOFROM,
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index 51ab96e..a6c39cd 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -764,7 +764,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask,
if ((mask & OMP_CLAUSE_DELETE)
&& gfc_match ("delete ( ") == MATCH_YES
&& gfc_match_omp_map_clause (&c->lists[OMP_LIST_MAP],
- OMP_MAP_FORCE_DEALLOC))
+ OMP_MAP_DELETE))
continue;
if ((mask & OMP_CLAUSE_PRESENT)
&& gfc_match ("present ( ") == MATCH_YES
diff --git gcc/fortran/trans-openmp.c gcc/fortran/trans-openmp.c
index 5990202..a905ca6 100644
--- gcc/fortran/trans-openmp.c
+++ gcc/fortran/trans-openmp.c
@@ -2119,12 +2119,12 @@ gfc_trans_omp_clauses (stmtblock_t *block,
gfc_omp_clauses *clauses,
case OMP_MAP_TOFROM:
OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_TOFROM);
break;
+ case OMP_MAP_DELETE:
+ OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_DELETE);
+ break;
case OMP_MAP_FORCE_ALLOC:
OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_ALLOC);
break;
- case OMP_MAP_FORCE_DEALLOC:
- OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_DEALLOC);
- break;
case OMP_MAP_FORCE_TO:
OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_TO);
break;
diff --git gcc/gimplify.c gcc/gimplify.c
index f3e5c39..3687e7a 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -8194,7 +8194,7 @@ gimplify_oacc_declare_1 (tree clause)
case GOMP_MAP_ALLOC:
case GOMP_MAP_FORCE_ALLOC:
case GOMP_MAP_FORCE_TO:
- new_op = GOMP_MAP_FORCE_DEALLOC;
+
Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class
On 03/16/2016 07:55 AM, H.J. Lu wrote: On Tue, Mar 15, 2016 at 7:51 PM, Jason Merrill wrote: On 03/15/2016 08:25 PM, Joseph Myers wrote: On Tue, 15 Mar 2016, H.J. Lu wrote: On Tue, Mar 15, 2016 at 3:34 PM, Joseph Myers wrote: On Tue, 15 Mar 2016, H.J. Lu wrote: On Tue, Mar 15, 2016 at 2:39 PM, Joseph Myers wrote: I'm not sure if the zero-size arrays (a GNU extension) are considered to make a struct non-empty, but in any case I think the tests should cover such arrays as elements of structs. There are couple tests for structs with members of array of empty types. testsuite/g++.dg/abi/empty14.h has My concern is the other way round - structs with elements such as "int a[0];", an array [0] of a nonempty type. My reading of the subobject definition is that such an array should not cause the struct to be considered nonempty (it doesn't result in any int subobjects). This is a test for struct with zero-size array, which isn't treated as empty type. C++ and C are compatible in its passing. Where is the current definition of empty types you're proposing for use in GCC? Is the behavior of this case clear from that definition? "An empty type is a type where it and all of its subobjects (recursively) are of structure, union, or array type. No memory slot nor register should be used to pass or return an object of empty type." It seems to me that such a struct should be considered an empty type under this definition, since a zero-length array has no subobjects. Since zero-size array is GCC extension, we can change it. Do we want to change its passing for C? I would think so; it seems to follow clearly from this definition. I have trouble imagining that anyone would ever pass an object containing a zero-length array by value, so it shouldn't matter much either way, but I consistency is good. Jason
Re: [patch] libstdc++/69945 Add __gnu_cxx::__freeres hook
On Thu, 2016-03-03 at 16:34 +0100, Mark Wielaard wrote: > On Wed, 2016-02-24 at 18:35 +, Jonathan Wakely wrote: > > This adds a new function to libsupc++ which will free the memory still > > in use by the pool used for allocating exceptions when malloc fails. > > > > This is similar to glibc's __libc_freeres, which valgrind (and other > > tools?) use to tell glibc to deallocate everything before exiting. > > > > I initially called it __gnu_cxx::__free_eh_pool() but I figured we > > might have other memory in use at some later date, and we wouldn't > > want valgrind to have to start calling a second function, nor make a > > function called __free_eh_pool() actually free other things. > > I tested this on x86_64-pc-linux-gnu with Ivo's valgrind patch from > https://bugs.kde.org/show_bug.cgi?id=345307 and it works pretty nicely. > No more spurious still reachable memory issues with memcheck. > > Is there any possibility to get this backported for 5.4? If there is anything I can do to help move this patch forward, please let me know. Thanks, Mark
[GCC][ARM] Skip tests that assume target supports arm mode, when testing M profiles
Hello,
This patch skips four tests that assume a target supports ARM mode when
testing M-profiles.
Tested it by running the four tests for A-profiles and M-profiles.
Is this ok?
Cheers,
Andre
gcc/testsuite/ChangeLog:
2016-03-17 Andre Vieira
* gcc/testsuite/gcc.target/arm/attr-align1.c: Skip if M-profile.
* gcc/testsuite/gcc.target/arm/attr-align3.c: Likewise.
* gcc/testsuite/gcc.target/arm/attr_arm.c: Likewise.
* gcc/testsuite/gcc.target/arm/flip-thumb.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/arm/attr-align1.c
b/gcc/testsuite/gcc.target/arm/attr-align1.c
index
96d29a9eed5a81306cb90393a2eb4fe7236ae50b..a53f16706860b69fcc60071b818fbc9f89fc33c7
100644
--- a/gcc/testsuite/gcc.target/arm/attr-align1.c
+++ b/gcc/testsuite/gcc.target/arm/attr-align1.c
@@ -2,6 +2,7 @@
Verify alignment when both attribute optimize and target are used. */
/* { dg-do compile } */
/* { dg-skip-if "" { ! { arm_thumb1_ok || arm_thumb2_ok } } } */
+/* { dg-skip-if "" arm_cortex_m } */
void
__attribute__ ((target ("arm")))
diff --git a/gcc/testsuite/gcc.target/arm/attr-align3.c
b/gcc/testsuite/gcc.target/arm/attr-align3.c
index
edcf64b45e053eca4ae5f0be2de3afd7b674f464..593d7fbc2b999d264cb06f54363c471480117f32
100644
--- a/gcc/testsuite/gcc.target/arm/attr-align3.c
+++ b/gcc/testsuite/gcc.target/arm/attr-align3.c
@@ -2,6 +2,7 @@
Verify alignment when attribute target is used. */
/* { dg-do compile } */
/* { dg-skip-if "" { ! { arm_thumb1_ok || arm_thumb2_ok } } } */
+/* { dg-skip-if "" arm_cortex_m } */
/* { dg-options "-Os -mthumb" } */
/* Check that arm code is always 4 bytes aligned. */
diff --git a/gcc/testsuite/gcc.target/arm/attr_arm.c
b/gcc/testsuite/gcc.target/arm/attr_arm.c
index
f5c70ef690fc68425e0c4a0f458cd73ebde2f0ab..d765d121e2965a440234a1793688bc97aa60d831
100644
--- a/gcc/testsuite/gcc.target/arm/attr_arm.c
+++ b/gcc/testsuite/gcc.target/arm/attr_arm.c
@@ -1,5 +1,6 @@
/* Check that attribute target arm is recognized. */
/* { dg-do compile } */
+/* { dg-skip-if "" arm_cortex_m } */
/* { dg-final { scan-assembler "\\.arm" } } */
/* { dg-final { scan-assembler-not "\\.thumb_func" } } */
diff --git a/gcc/testsuite/gcc.target/arm/flip-thumb.c
b/gcc/testsuite/gcc.target/arm/flip-thumb.c
index
355d66377558d9007f58056180940122fcf148e0..4bbe546b6325b2cbc9f9b7f7c52c29815c231916
100644
--- a/gcc/testsuite/gcc.target/arm/flip-thumb.c
+++ b/gcc/testsuite/gcc.target/arm/flip-thumb.c
@@ -2,6 +2,7 @@
/* { dg-do compile } */
/* Make sure the current multilib supports thumb. */
/* { dg-skip-if "" { ! { arm_thumb1_ok || arm_thumb2_ok } } } */
+/* { dg-skip-if "" arm_cortex_m } */
/* { dg-options "-O2 -mflip-thumb -mno-restrict-it" } */
/* { dg-final { scan-assembler "\\.arm" } } */
/* { dg-final { scan-assembler-times "\\.thumb_func" 1} } */
[PATCH] PR testsuite/70150: Check pie_enabled target in PIC tests
We need to check pie_enabled target in PIC tests to support GCC where
PIE is enabled by default when configured with --enable-default-pie.
OK for master?
H.J.
---
PR testsuite/70150
* gcc.dg/20020312-2.c (dg-additional-options): Set to "-no-pie"
for pie_enabled target.
* gcc.dg/uninit-19.c: Check pie_enabled for PIC.
* gcc.target/i386/pr34256.c: Likewise.
---
gcc/testsuite/gcc.dg/20020312-2.c | 1 +
gcc/testsuite/gcc.dg/uninit-19.c| 4 ++--
gcc/testsuite/gcc.target/i386/pr34256.c | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/20020312-2.c
b/gcc/testsuite/gcc.dg/20020312-2.c
index 5fce50d..5c5cb09 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -7,6 +7,7 @@
/* { dg-do run } */
/* { dg-options "-O -fno-pic" } */
+/* { dg-additional-options "-no-pie" { target pie_enabled } } */
/* { dg-require-effective-target nonlocal_goto } */
extern void abort (void);
diff --git a/gcc/testsuite/gcc.dg/uninit-19.c b/gcc/testsuite/gcc.dg/uninit-19.c
index d7b9ed0..8c2bbeb 100644
--- a/gcc/testsuite/gcc.dg/uninit-19.c
+++ b/gcc/testsuite/gcc.dg/uninit-19.c
@@ -22,5 +22,5 @@ fn2 ()
fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
}
-/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
-/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */
+/* { dg-warning "may be used uninitialized" "" { target { nonpic ||
pie_enabled } } 13 } */
+/* { dg-warning "may be used uninitialized" "" { target { { ! nonpic } && { !
pie_enabled } } } 22 } */
diff --git a/gcc/testsuite/gcc.target/i386/pr34256.c
b/gcc/testsuite/gcc.target/i386/pr34256.c
index 992312a..6987457 100644
--- a/gcc/testsuite/gcc.target/i386/pr34256.c
+++ b/gcc/testsuite/gcc.target/i386/pr34256.c
@@ -10,5 +10,5 @@ unsigned long long foo(__m64 m) {
return _mm_cvtm64_si64(_mm_add_pi32(x, y));
}
-/* { dg-final { scan-assembler-times "mov" 2 { target nonpic } } } */
-/* { dg-final { scan-assembler-times "mov" 4 { target { ! nonpic } } } } */
+/* { dg-final { scan-assembler-times "mov" 2 { target { nonpic || pie_enabled
} } } } */
+/* { dg-final { scan-assembler-times "mov" 4 { target { { ! nonpic } && { !
pie_enabled } } } } } */
--
2.5.0
Re: [PATCH] Fix PR64764
On Wed, Mar 16, 2016 at 9:41 AM, H.J. Lu wrote:
> On Wed, Mar 16, 2016 at 9:35 AM, Tom de Vries wrote:
>> On 16/03/16 17:15, H.J. Lu wrote:
>>>
>>> On Wed, Mar 16, 2016 at 9:12 AM, H.J. Lu wrote:
>>
>>
Any particular reason why this test was changed to DOS format?
>>
>>
>> FWIW, the test was in DOS format from the start.
>>
>>
>
> DOS format was introduced by r220530:
>
> Index: gcc.dg/uninit-19.c
> ===
> --- gcc.dg/uninit-19.c (revision 220529)
> +++ gcc.dg/uninit-19.c (revision 220530)
> @@ -10,7 +10,7 @@ fn1 (int p1, float *f1, float *f2, float
> unsigned char *c2, float *p10)^M
> {^M
>if (p1 & 8)^M
> -b[3] = p10[a]; /* { dg-warning "may be used uninitialized" } */^M
> +b[3] = p10[a]; /* 13. */^M
> }^M
> ^M
> void^M
> @@ -19,5 +19,8 @@ fn2 ()
>float *n;^M
>if (l & 6)^M
> n = &c + m;^M
> - fn1 (l, &d, &e, &g, &i, &h, &k, n);^M
> + fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */^M
> }^M
> +^M
> +/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */^M
> +/* { dg-warning "may be used uninitialized" "" { target { ! nonpic }
> } 22 } */^M
>
> "^M" was added to those changed lines.
>
Never mind. "^M" was there before.
--
H.J.
Re: RFA: PATCH to load_register_parameters for empty structs and sibcalls
On 03/16/2016 07:45 PM, Jason Merrill wrote:
Discussion of empty class parameter passing ABI led me to notice that
r162402 broke sibcalls with arguments of size 0 in some cases. Before
that commit, the code read
else if ((partial == 0 || args[i].pass_on_stack)
&& size != 0)
{
[...]
if (is_sibcall
&& mem_overlaps_already_clobbered_arg_p (XEXP (args[i].value,
0), size))
*sibcall_failure = 1;
and after,
if (is_sibcall
&& (size == 0
|| mem_overlaps_already_clobbered_arg_p
(XEXP (args[i].value, 0),
size)))
So now we set *sibcall_failure if size==0, whereas before we didn't
enter the outer block. The comment also contradicts the code.
The patch looks ok. I was trying to research the earlier change, but I
can't find a message in the archives. Cc'ing Iain in case he has input.
Bernd
Re: [PATCH, PR70185] Only finalize dot files that have been initialized
On Wed, Mar 16, 2016 at 11:57 AM, Tom de Vries wrote:
> Hi,
>
> Atm, using fdump-tree-all-graph produces invalid dot files:
> ...
> $ rm *.c.* ; gcc test.c -O2 -S -fdump-tree-all-graph
> $ for f in *.dot; do dot -Tpdf $f -o dot.pdf; done
> Warning: test.c.006t.omplower.dot: syntax error in line 1 near '}'
> Warning: test.c.007t.lower.dot: syntax error in line 1 near '}'
> Warning: test.c.010t.eh.dot: syntax error in line 1 near '}'
> Warning: test.c.292t.statistics.dot: syntax error in line 1 near '}'
> $ cat test.c.006t.omplower.dot
> }
> $
> ...
> These dot files are finalized, but never initialized or used.
>
> The 006/007/010 files are not used because '(fn->curr_properties & PROP_cfg)
> == 0' at the corresponding passes.
>
> And the file test.c.292t.statistics.dot is not used, because it doesn't
> belong to a single pass.
>
> The current finalization code doesn't handle these cases:
> ...
> /* Do whatever is necessary to finish printing the graphs. */
> for (i = TDI_end; (dfi = dumps->get_dump_file_info (i)) != NULL; ++i)
> if (dumps->dump_initialized_p (i)
> && (dfi->pflags & TDF_GRAPH) != 0
> && (name = dumps->get_dump_file_name (i)) != NULL)
> {
> finish_graph_dump_file (name);
> free (name);
> }
> ...
>
> The patch fixes this by simply testing for pass->graph_dump_initialized
> instead.
>
> [ That fix exposes the lack of initialization of graph_dump_initialized. It
> seems to be initialized for static passes, but for dynamically added passes,
> such as f.i. vzeroupper the value is uninitialized. The patch also fixes
> this. ]
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for stage1?
Seeing this I wonder if it makes more sense to move ->graph_dump_initialized
from pass to dump_file_info? Also in the above shouldn't it use
dfi->pfilename rather than dumps->get_dump_file_name (i)?
Richard.
> Thanks,
> - Tom
Re: Please include ada-hurd.diff upstream (try2)
> > The copyright notices are wrong (or at least incomplete). > > Hi, what is wrong then, copyright years and/or the text? Both. The copyright year should include 2016 and the text should be copyright FSF, not AdaCore. Arno
[gomp4] Merge trunk r234323 (2016-03-18) into gomp-4_0-branch
Hi! Committed to gomp-4_0-branch in r234351: commit 4514391426e57f78cb3bfd66d09f5065eff66243 Merge: 2d2924a 666094f Author: tschwinge Date: Sat Mar 19 15:34:52 2016 + svn merge -r 232931:234323 svn+ssh://gcc.gnu.org/svn/gcc/trunk git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@234351 138bc75d-0d04-0410-961f-82ee72b054a4 Grüße Thomas
[PATCH] PR lto/70258: [6 Regression] flag_pic is cleared for PIE in lto_post_options
Since PIE implies PIC, we should set flag_pic to flag_pie for PIE in LTO. Tested on x86-64. OK for trunk? H.J. --- PR lto/70258 * lto-lang.c (lto_post_options): Set flag_pic to flag_pie for PIE. --- gcc/lto/lto-lang.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c index 691e9e2..b5efe3a 100644 --- a/gcc/lto/lto-lang.c +++ b/gcc/lto/lto-lang.c @@ -836,7 +836,7 @@ lto_post_options (const char **pfilename ATTRIBUTE_UNUSED) /* If -fPIC or -fPIE was used at compile time, be sure that flag_pie is 2. */ flag_pie = MAX (flag_pie, flag_pic); - flag_pic = 0; + flag_pic = flag_pie; break; case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */ -- 2.5.0
Re: [PATCH] Fix PR64764
On Wed, Mar 16, 2016 at 9:12 AM, H.J. Lu wrote:
> On Mon, Feb 9, 2015 at 2:30 AM, Tom de Vries wrote:
>> On 09-02-15 09:59, Richard Biener wrote:
>>>
>>> On Thu, 5 Feb 2015, Tom de Vries wrote:
>>>
On 26-01-15 15:47, Richard Biener wrote:
>
> Index: gcc/testsuite/gcc.dg/uninit-19.c
> ===
> --- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
> +++ gcc/testsuite/gcc.dg/uninit-19.c(working copy)
> @@ -0,0 +1,23 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -Wuninitialized" } */
> +
> +int a, l, m;
> +float *b;
> +float c, d, e, g, h;
> +unsigned char i, k;
> +void
> +fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float
> *f4,
> + unsigned char *c2, float *p10)
> +{
> + if (p1 & 8)
> +b[3] = p10[a]; /* { dg-warning "may be used uninitialized" } */
> +}
> +
> +void
> +fn2 ()
> +{
> + float *n;
> + if (l & 6)
> +n = &c + m;
> + fn1 (l, &d, &e, &g, &i, &h, &k, n);
> +}
Hi Richard,
this new test fails with -fpic, because fn1 is not inlined.
Adding static to fn1 allows it to pass both with and without -fpic. But
that
change might affect whether it still serves as a regression test for this
PR,
I'm not sure.
Another way to fix this could be to use the warning line number 22
instead 13
for fpic.
>>>
>>>
>>> Either way is fine with me.
>>>
>>
>> Committed using the method of different line number for -fpic.
>>
>> Thanks,
>> - Tom
>>
>> 2015-02-09 Tom de Vries
>>
>> * gcc.dg/uninit-19.c: Fix warning line for fpic.
>> ---
>> gcc/testsuite/gcc.dg/uninit-19.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/testsuite/gcc.dg/uninit-19.c
>> b/gcc/testsuite/gcc.dg/uninit-19.c
>> index 3113cab..fc7acea 100644
>> --- a/gcc/testsuite/gcc.dg/uninit-19.c
>> +++ b/gcc/testsuite/gcc.dg/uninit-19.c
>> @@ -10,7 +10,7 @@ fn1 (int p1, float *f1, float *f2, float *f3, unsigned
>> char *c1, float *f4,
>> unsigned char *c2, float *p10)
>> {
>>if (p1 & 8)
>> -b[3] = p10[a]; /* { dg-warning "may be used uninitialized" } */
>> +b[3] = p10[a]; /* 13. */
>> }
>>
>> void
>> @@ -19,5 +19,8 @@ fn2 ()
>>float *n;
>>if (l & 6)
>> n = &c + m;
>> - fn1 (l, &d, &e, &g, &i, &h, &k, n);
>> + fn1 (l, &d, &e, &g, &i, &h, &k, n); /* 22. */
>> }
>> +
>> +/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
>> +/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 }
>> */
>> --
>> 1.9.1
>>
>
> Any particular reason why this test was changed to DOS format?
>
I ran dos2unix on gcc.dg/uninit-19.c and checked it in.
--
H.J.
Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class
On 03/16/2016 03:39 PM, H.J. Lu wrote: On Wed, Mar 16, 2016 at 10:02 AM, H.J. Lu wrote: On Wed, Mar 16, 2016 at 9:58 AM, Jason Merrill wrote: On 03/16/2016 08:38 AM, H.J. Lu wrote: FAIL: g++.dg/abi/pr60336-1.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-5.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-6.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-7.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr60336-9.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type FAIL: g++.dg/abi/pr68355.C scan-assembler jmp[\t ]+[^$]*?_Z3xxx17integral_constantIbLb1EE These pass for me on x86_64, but I do see calls with -m32. They are expected since get_ref_base_and_extent needs to be changed to set bitsize to 0 for empty types so that when ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to get 0 as the maximum size on empty type. Otherwise, find_tail_calls won't perform tail call optimization for functions with empty type parameters. That isn't why the optimization isn't happening in pr68355 with -m32; the .optimized dump has xxx (D.2289); [tail call] Rather, the failure seems to happen in load_register_parameter, at /* Check for overlap with already clobbered argument area, providing that this has non-zero size. */ if (is_sibcall && (size == 0 || mem_overlaps_already_clobbered_arg_p (XEXP (args[i].value, 0), size))) *sibcall_failure = 1; The code seems to contradict the comment, and seems to have been broken by r162402. Applying this additional patch fixes those tests. I am running the full test now. On x86-64, I got export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/ubsan/object-size-9.c:11:13: runtime error: load of address 0x00600ffa with insufficient space for an object of type 'char' 0x00600ffa: note: pointer points here PASS: gcc.dg/ubsan/object-size-9.c -O2 execution test FAIL: gcc.dg/ubsan/object-size-9.c -O2 output pattern test Output was: That looks like a dejagnu glitch; the output you quote seems to match the expected output from the test. Jason
Re: [PATCH, 16/16] Add libgomp.oacc-fortran/kernels-*.f95
Hi!
On Wed, 9 Mar 2016 10:19:09 +0100, Tom de Vries wrote:
> On 09/11/15 21:12, Tom de Vries wrote:
> > This patch adds Fortran oacc kernels execution tests.
>
> Retested on current trunk.
>
> Committed, minus the kernels-parallel-loop-data-enter-exit.f95 test.
As obvious, committed in r234257:
commit baeaf028bfed958e14abc8b9f3ca10949bacaf97
Author: tschwinge
Date: Wed Mar 16 13:10:20 2016 +
Nowadays, we use plain -fopenacc to enable OpenACC kernels processing
libgomp/
* testsuite/libgomp.oacc-fortran/kernels-loop-2.f95: Adjust to
-ftree-parallelize-loops/-fopenacc changes.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data.f95: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop.f95: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234257
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgomp/ChangeLog | 15 +++
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-2.f95 | 1 -
.../libgomp.oacc-fortran/kernels-loop-data-2.f95 | 1 -
.../kernels-loop-data-enter-exit-2.f95| 1 -
.../libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95 | 1 -
.../libgomp.oacc-fortran/kernels-loop-data-update.f95 | 1 -
.../testsuite/libgomp.oacc-fortran/kernels-loop-data.f95 | 1 -
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop.f95 | 1 -
8 files changed, 15 insertions(+), 7 deletions(-)
diff --git libgomp/ChangeLog libgomp/ChangeLog
index 5a91504..fca65e6 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,18 @@
+2016-03-16 Thomas Schwinge
+
+ * testsuite/libgomp.oacc-fortran/kernels-loop-2.f95: Adjust to
+ -ftree-parallelize-loops/-fopenacc changes.
+ * testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95:
+ Likewise.
+ * testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95:
+ Likewise.
+ * testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95:
+ Likewise.
+ * testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95:
+ Likewise.
+ * testsuite/libgomp.oacc-fortran/kernels-loop-data.f95: Likewise.
+ * testsuite/libgomp.oacc-fortran/kernels-loop.f95: Likewise.
+
2016-03-13 Thomas Schwinge
* testsuite/lib/libgomp.exp (libgomp_init): Potentially append to
diff --git libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-2.f95
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-2.f95
index 1fb40ee..163e8d5 100644
--- libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-2.f95
+++ libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-2.f95
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-ftree-parallelize-loops=32" }
program main
implicit none
diff --git libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95
index 7b52253..4c73606 100644
--- libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95
+++ libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-ftree-parallelize-loops=32" }
program main
implicit none
diff --git
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95
index af98efa..da11aaf 100644
--- libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95
+++ libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-ftree-parallelize-loops=32" }
program main
implicit none
diff --git
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95
index bb6f8dc..f4b4eb3 100644
--- libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95
+++ libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-ftree-parallelize-loops=32" }
program main
implicit none
diff --git libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95
libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95
index cab1f2c..d2083e2 100644
--- libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95
+++ libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95
@@ -1,5 +1,4 @@
! { dg-do run }
-! { dg-options "-ftree-parallelize-loops=32" }
program main
implicit none
diff --git libgomp/testsuite/libgomp.oacc-fortran/kernels-loop-data.f95
libgomp/testsuite/libgomp
Re: [PATCH PR69489/01]Improve tree ifcvt by storing/tracking DR against its innermost loop bahavior if possible
On Wed, Mar 16, 2016 at 5:17 PM, Bin.Cheng wrote:
> On Wed, Mar 16, 2016 at 12:20 PM, Richard Biener
> wrote:
>>
>> On Wed, Mar 16, 2016 at 10:59 AM, Bin Cheng wrote:
>> > Hi,
>> > ..
>> > Bootstrap and test on x86_64 and AArch64. Is it OK, not sure if it's GCC
>> > 7?
>>
>> Hmm.
> Hi,
> Thanks for reviewing.
>>
>> + equal_p = true;
>> + if (e1->base_address && e2->base_address)
>> +equal_p &= operand_equal_p (e1->base_address, e2->base_address, 0);
>> + if (e1->offset && e2->offset)
>> +equal_p &= operand_equal_p (e1->offset, e2->offset, 0);
>>
>> surely better to return false early.
>>
>> I think we don't want this in tree-data-refs.h also because of ...
>>
>> @@ -615,15 +619,29 @@
>> hash_memrefs_baserefs_and_store_DRs_read_written_info
>> (data_reference_p a)
>>data_reference_p *master_dr, *base_master_dr;and REALPART) before
>> creating the DR (or adjust the equality function
> and hashing
>>tree ref = DR_REF (a);
>>tree base_ref = DR_BASE_OBJECT (a);
>> + innermost_loop_behavior *innermost = &DR_INNERMOST (a);
>>tree ca = bb_predicate (gimple_bb (DR_STMT (a)));
>>bool exist1, exist2;
>>
>> - while (TREE_CODE (ref) == COMPONENT_REF
>> -|| TREE_CODE (ref) == IMAGPART_EXPR
>> -|| TREE_CODE (ref) == REALPART_EXPR)
>> -ref = TREE_OPERAND (ref, 0);
>> + /* If reference in DR has innermost loop behavior and it is not
>> + a compound memory reference, we store it to innermost_DR_map,
>> + otherwise to ref_DR_map. */
>> + if (TREE_CODE (ref) == COMPONENT_REF
>> + || TREE_CODE (ref) == IMAGPART_EXPR
>> + || TREE_CODE (ref) == REALPART_EXPR
>> + || !(DR_BASE_ADDRESS (a) || DR_OFFSET (a)
>> + || DR_INIT (a) || DR_STEP (a) || DR_ALIGNED_TO (a)))
>> +{
>> + while (TREE_CODE (ref) == COMPONENT_REF
>> +|| TREE_CODE (ref) == IMAGPART_EXPR
>> +|| TREE_CODE (ref) == REALPART_EXPR)
>> + ref = TREE_OPERAND (ref, 0);
>> +
>> + master_dr = &ref_DR_map->get_or_insert (ref, &exist1);
>> +}
>> + else
>> +master_dr = &innermost_DR_map->get_or_insert (innermost, &exist1);
>>
>> we don't want an extra hashmap but replace ref_DR_map entirely. So we'd
>> need to
>> strip outermost non-variant handled-components (COMPONENT_REF, IMAGPART
>> and REALPART) before creating the DR (or adjust the equality function
>> and hashing
>> to disregard them which means subtracting their offset from DR_INIT.
> I am not sure if I understand correctly. But for component reference,
> it is the base object that we want to record/track. For example,
>
> for (i = 0; i < N; i++) {
> m = *data++;
>
> m1 = p1->x - m;
> m2 = p2->x + m;
>
> p3->y = (m1 >= m2) ? p1->y : p2->y;
>
> p1++;
> p2++;
> p3++;
> }
> We want to infer that reads of p1/p2 in condition statement won't trap
> because there are unconditional reads of the structures, though the
> unconditional reads are actual of other sub-objects. Here it is the
> invariant part of address that we want to track.
Well, the variant parts - we want to strip invariant parts as far as we can
(offsetof (x) and offsetof (y))
> Also illustrated by this example, we can't rely on data-ref analyzer
> here. Because in gathering/scattering cases, the address could be not
> affine at all.
Sure, but that's a different issue.
>>
>> To adjust the references we collect you'd maybe could use a callback
>> to get_references_in_stmt
>> to adjust them.
>>
>> OTOH post-processing the DRs in if_convertible_loop_p_1 can be as simple as
> Is this a part of the method you suggested above, or is it an
> alternative one? If it's the latter, then I have below questions
> embedded.
It is an alternative to adding a hook to get_references_in_stmt and
probably "easier".
>>
>> Index: tree-if-conv.c
>> ===
>> --- tree-if-conv.c (revision 234215)
>> +++ tree-if-conv.c (working copy)
>> @@ -1235,6 +1220,38 @@ if_convertible_loop_p_1 (struct loop *lo
>>
>>for (i = 0; refs->iterate (i, &dr); i++)
>> {
>> + tree *refp = &DR_REF (dr);
>> + while ((TREE_CODE (*refp) == COMPONENT_REF
>> + && TREE_OPERAND (*refp, 2) == NULL_TREE)
>> +|| TREE_CODE (*refp) == IMAGPART_EXPR
>> +|| TREE_CODE (*refp) == REALPART_EXPR)
>> + refp = &TREE_OPERAND (*refp, 0);
>> + if (refp != &DR_REF (dr))
>> + {
>> + tree saved_base = *refp;
>> + *refp = integer_zero_node;
>> +
>> + if (DR_INIT (dr))
>> + {
>> + tree poffset;
>> + int punsignedp, preversep, pvolatilep;
>> + machine_mode pmode;
>> + HOST_WIDE_INT pbitsize, pbitpos;
>> + get_inner_reference (DR_REF (dr), &pbitsize, &pbitpos,
>> &poffset,
>> + &pmode, &punsignedp, &preversep,
>> &pvolatilep,
>> + false);
>> +
Re: [PATCH, match] Fix pr68714
On Tue, Mar 15, 2016 at 08:09:54AM -0700, Richard Henderson wrote:
> Ah, sure. I should have simply tested the reassoc1 dump file, before
> generic vector lowering.
The testcase fails on i386 (and I assume fails on powerpc too), due to the
psABI warnings/notes.
I've committed this as obvious.
2016-03-16 Jakub Jelinek
PR tree-optimization/68714
* gcc.dg/tree-ssa/pr68714.c: Add -w -Wno-psabi to dg-options.
--- gcc/testsuite/gcc.dg/tree-ssa/pr68714.c.jj 2016-03-15 17:10:18.627539190
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr68714.c 2016-03-16 14:20:34.160133852
+0100
@@ -1,5 +1,6 @@
+/* PR tree-optimization/68714 */
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-reassoc1" } */
+/* { dg-options "-O2 -fdump-tree-reassoc1 -w -Wno-psabi" } */
typedef int vec __attribute__((vector_size(16)));
vec f(vec x,vec y){
Jakub
Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic
On 03/17/2016 04:26 PM, H.J. Lu wrote: On Thu, Mar 17, 2016 at 8:23 AM, Bernd Schmidt wrote: On 03/17/2016 04:13 PM, H.J. Lu wrote: We can add an effective target, something like ignore_pic_pie, and use it instead of *-*-darwin*. That should have been done _before_ committing the patch in a form that was not approved. How should we move forward? Maybe an effective target pic_default, which tests whether __PIC__ is defined without any options. Please prepare a patch. Bernd
Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419
On 14/03/16 15:34, Christophe Lyon wrote: > On 10 March 2016 at 14:24, James Greenhalgh wrote: >> On Thu, Mar 10, 2016 at 01:37:50PM +0100, Christophe Lyon wrote: >>> On 10 March 2016 at 12:43, James Greenhalgh >>> wrote: On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote: > With the attachment > > > On 26 January 2016 at 15:42, Christophe Lyon > wrote: >> Hi, >> >> This is a followup to PR63304. >> >> As discussed in bugzilla, this patch disables pcrelative_literal_loads >> when -mfix-cortex-a53-843419 (or its default configure option) is >> used. >> >> I copied the behavior of -mfix-cortex-a53-835769 (e.g. in >> aarch64_can_inline_p), and I have tested by building the Linux kernel >> using -mfix-cortex-a53-843419 and checked that >> R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under >> CONFIG_ARM64_ERRATUM_843419). >> >> For reference, this is motivated by: >> https://bugs.linaro.org/show_bug.cgi?id=1994 >> and further details on Launchpad: >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009 >> >> OK for trunk? Thanks, this looks like a clear regression from GCC 5 (we can no longer build the kernel, so this workaround is fine to go in now). Please remember to add the link to the relevant PR in the ChangeLog. I'd also really appreciate a nice big comment over this code: > + /* If it is not set on the command line, we default to no pc > + relative literal loads, unless the workaround for Cortex-A53 > + erratum 843419 is in effect. */ > + if (opts->x_nopcrelative_literal_loads == 2 > + && !TARGET_FIX_ERR_A53_843419) Explaining why this is important (i.e. some summary of the discussion in PR63304 regarding the kernel module loader). Can you repost with that comment added? I don't have any other objections to the patch. >>> >>> OK, here is an updated version. >> >> Thanks. >> >> This is OK for trunk. >> > > When GCC is configured to enable the A53 erratum 843419 workaround by default, > this patch caused gcc.target/aarch64/pr63304_1.c to fail. > > The attached patch fixes the problem by forcing the use of > -mno-fix-cortex-a53-843419. > > OK, or do we prefer not to bother? > > Thanks, > > Christophe > > >> James >> >> >> pr70113.log.txt >> >> >> 2016-03-14 Christophe Lyon >> >> * gcc.target/aarch64/pr63304_1.c: Add -mno-fix-cortex-a53-843419. >> OK. R.
Re: [PATCH, PR tree-optimization/70252] Fix boolean vectors conversion
On Thu, Mar 17, 2016 at 1:02 PM, Ilya Enkovich wrote:
> Hi,
>
> Current widening and narrowing vectorization functions may work
> incorrectly for scalar masks because we may have different boolean
> vector types having the same mode. E.g. vec(4) and vec(8)
> both have QImode. That means if we need to convert vec(4) into
> vec(16) we may actually find QImode->HImode conversion optab
> and try to use it which is incorrect because this optab entry is
> used for vec(8) to vec(16) conversion.
>
> I suppose the best fix for GCC 6 is to just catch and disable such
> conversion by checking number of vetor elements. It doesn't disable
> any vectorization because we don't have any conversion patterns
> for vec(4) anyway.
>
> It's not clear what to do for GCC 7 though to enable such conversions.
> It looks like for AVX-512 we have three boolean vectors sharing the
> same QImode: vec(2), vec(4) and vec(8). It means
> we can't use optabs to check operations on these vectors even
> using conversion optabs instead of direct ones. Can we use half/quarter
> byte modes for such masks or something like that? Another option is to
> handle their conversion separately with no optabs usage at all (target
> hooks?).
>
> The patch was bootstrapped and regtested on x86_64-unknown-linux-gnu.
> OK for trunk?
Ok.
Richard.
> Thanks,
> Ilya
> --
> gcc/
>
> 2016-03-17 Ilya Enkovich
>
> PR tree-optimization/70252
> * tree-vect-stmts.c (supportable_widening_operation): Check resulting
> boolean vector has a proper number of elements.
> (supportable_narrowing_operation): Likewise.
>
> gcc/testsuite/
>
> 2016-03-17 Ilya Enkovich
>
> PR tree-optimization/70252
> * gcc.dg/pr70252.c: New test.
>
>
> diff --git a/gcc/testsuite/gcc.dg/pr70252.c b/gcc/testsuite/gcc.dg/pr70252.c
> new file mode 100644
> index 000..209e691
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr70252.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3" } */
> +/* { dg-additional-options "-march=skylake-avx512" { target { i?86-*-*
> x86_64-*-* } } } */
> +
> +extern unsigned char a [150];
> +extern unsigned char b [150];
> +extern unsigned char c [150];
> +extern unsigned char d [150];
> +extern unsigned char e [150];
> +
> +void foo () {
> + for (int i = 92; i <= 141; i += 2) {
> +int tmp = (d [i] && b [i]) <= (a [i] > c [i]);
> +e [i] = tmp >> b [i];
> + }
> +}
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 06b1ab7..d12c062 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -8940,7 +8940,12 @@ supportable_widening_operation (enum tree_code code,
> gimple *stmt,
>
>if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype)
>&& insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype))
> -return true;
> + /* For scalar masks we may have different boolean
> +vector types having the same QImode. Thus we
> +add additional check for elements number. */
> +return (!VECTOR_BOOLEAN_TYPE_P (vectype)
> + || (TYPE_VECTOR_SUBPARTS (vectype) / 2
> + == TYPE_VECTOR_SUBPARTS (wide_vectype)));
>
>/* Check if it's a multi-step conversion that can be done using
> intermediate
> types. */
> @@ -8991,7 +8996,9 @@ supportable_widening_operation (enum tree_code code,
> gimple *stmt,
>
>if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype)
> && insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype))
> - return true;
> + return (!VECTOR_BOOLEAN_TYPE_P (vectype)
> + || (TYPE_VECTOR_SUBPARTS (intermediate_type) / 2
> + == TYPE_VECTOR_SUBPARTS (wide_vectype)));
>
>prev_type = intermediate_type;
>prev_mode = intermediate_mode;
> @@ -9075,7 +9082,12 @@ supportable_narrowing_operation (enum tree_code code,
>*code1 = c1;
>
>if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype))
> -return true;
> +/* For scalar masks we may have different boolean
> + vector types having the same QImode. Thus we
> + add additional check for elements number. */
> +return (!VECTOR_BOOLEAN_TYPE_P (vectype)
> + || (TYPE_VECTOR_SUBPARTS (vectype) * 2
> + == TYPE_VECTOR_SUBPARTS (narrow_vectype)));
>
>/* Check if it's a multi-step conversion that can be done using
> intermediate
> types. */
> @@ -9140,7 +9152,9 @@ supportable_narrowing_operation (enum tree_code code,
>(*multi_step_cvt)++;
>
>if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype))
> - return true;
> + return (!VECTOR_BOOLEAN_TYPE_P (vectype)
> + || (TYPE_VECTOR_SUBPARTS (intermediate_type) * 2
> + == TYPE_VECTOR_SUBPARTS (narrow_vectype)));
>
>prev_mode = intermediate_mode;
>prev_type = intermediate_type;
New French PO file for 'gcc' (version 6.1-b20160131)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-6.1-b20160131.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
C++ PATCH for c++/70259 (-flifetime-dse vs. empty bases)
The constructor for an empty class can't do the -flifetime-dse clobber
because when the class is used as a base it might be assigned the same
offset as a real base, so the clobber would mess with real data.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e1a5f038350d1881153d8f65359bd883f7452237
Author: Jason Merrill
Date: Wed Mar 16 13:46:32 2016 -0400
PR c++/70259
* decl.c (start_preparsed_function): Don't clobber an empty base.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 4ee4ccc..e783163 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14125,6 +14125,8 @@ start_preparsed_function (tree decl1, tree attrs, int flags)
&& (flag_lifetime_dse > 1)
&& DECL_CONSTRUCTOR_P (decl1)
&& !DECL_CLONED_FUNCTION_P (decl1)
+ /* Clobbering an empty base is harmful if it overlays real data. */
+ && !is_empty_class (current_class_type)
/* We can't clobber safely for an implicitly-defined default constructor
because part of the initialization might happen before we enter the
constructor, via AGGR_INIT_ZERO_FIRST (c++/68006). */
diff --git a/gcc/testsuite/g++.dg/opt/flifetime-dse5.C b/gcc/testsuite/g++.dg/opt/flifetime-dse5.C
new file mode 100644
index 000..2c49021
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/flifetime-dse5.C
@@ -0,0 +1,13 @@
+// PR c++/70259
+// { dg-options -O2 }
+// { dg-do run }
+
+struct Empty { };
+struct A { A() : a(true) { } bool a; };
+struct B : Empty { B() : Empty() { } };
+struct C : A, B { C() : A(), B() { } };
+int main() {
+ C c;
+ if ( c.a == false )
+__builtin_abort();
+};
Re: PING: [PATCH] PR driver/70192: Properly set flag_pie and flag_pic
On Thu, Mar 17, 2016 at 7:18 AM, Bernd Schmidt wrote:
> On 03/17/2016 02:59 PM, H.J. Lu wrote:
>>
>> On Fri, Mar 11, 2016 at 9:09 AM, H.J. Lu wrote:
>>>
>>> We can't set flag_pie to the default when flag_pic == 0, which may be
>>> set by -fno-pic or -fno-PIC, since the default value of flag_pie is
>>> non-zero when GCC is configured with --enable-default-pie. We need
>>> to initialize flag_pic to -1 so that we can tell if -fpic, -fPIC,
>>> -fno-pic or -fno-PIC is used.
>
>
>>> PR driver/70192
>>> * opts.c (finish_options): Don't set flag_pie to the default if
>>> -fpic, -fPIC, -fno-pic or -fno-PIC is used. Set flag_pic to 0
>>> if it is -1.
>
>
> I think this part is ok.
>
>>> diff --git a/gcc/testsuite/gcc.dg/pie-2.c b/gcc/testsuite/gcc.dg/pie-2.c
>>> new file mode 100644
>>> index 000..e185e51
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/pie-2.c
>>> @@ -0,0 +1,10 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-fPIE" } */
>>> +
>>> +#if __PIC__ != 2
>>> +# error __PIC__ is not 2!
>>> +#endif
>>> +
>>> +#if __PIE__ != 2
>>> +# error __PIE__ is not 2!
>>> +#endif
>
>
> In normal code that should probably use the "__PIC__ - 0" trick to guard
> against cases where the macro isn't defined, but I suppose we'd be getting
> an error in that case as well.
>
>
>>> diff --git a/gcc/testsuite/gcc.dg/pie-3.c b/gcc/testsuite/gcc.dg/pie-3.c
>>> new file mode 100644
>>> index 000..fe46c98
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/pie-3.c
>>> @@ -0,0 +1,10 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-fno-pie" } */
>>> +
>>> +#ifdef __PIC__
>>> +# error __PIC__ is defined!
>>> +#endif
>>> +
>>> +#ifdef __PIE__
>>> +# error __PIE__ is defined!
>>> +#endif
>>> diff --git a/gcc/testsuite/gcc.dg/pie-4.c b/gcc/testsuite/gcc.dg/pie-4.c
>>> new file mode 100644
>>> index 000..977baf0
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/pie-4.c
>>> @@ -0,0 +1,10 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-fno-PIE" } */
>>> +
>>> +#ifdef __PIC__
>>> +# error __PIC__ is defined!
>>> +#endif
>>> +
>>> +#ifdef __PIE__
>>> +# error __PIE__ is defined!
>>> +#endif
>
>>> diff --git a/gcc/testsuite/gcc.dg/pie-6.c b/gcc/testsuite/gcc.dg/pie-6.c
>>> new file mode 100644
>>> index 000..85529a8
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/pie-6.c
>>> @@ -0,0 +1,10 @@
>>> +/* { dg-do compile { target { ! pie_enabled } } } */
>>> +/* { dg-options "" } */
>>> +
>>> +#ifdef __PIC__
>>> +# error __PIC__ is defined!
>>> +#endif
>>> +
>>> +#ifdef __PIE__
>>> +# error __PIE__ is defined!
>>> +#endif
>
> These I'm not so sure about. I could imagine there are targets where pic is
> the default. I'd remove these tests or the test for __PIC__. So, ok with
> that change.
Darwin is such a target. Here is a follow-up patch I was planning to
submit. But I will remove __PIC__ instead.
--
H.J.
From ff1ef6e4e969b244984d1ae4c93960e36edd1334 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 11 Mar 2016 09:24:41 -0800
Subject: [PATCH] Skip some PIC/PIE tests for *-*-darwin* targets
Since Darwin defaults to PIC, not PIE, skip tests of default __PIC__
and __PIE__ setting for *-*-darwin* targets.
* gcc.dg/pic-1.c: Skip for *-*-darwin* targets.
* gcc.dg/pic-3.c: Likewise.
* gcc.dg/pic-4.c: Likewise.
* gcc.dg/pie-1.c: Likewise.
* gcc.dg/pie-3.c: Likewise.
* gcc.dg/pie-4.c: Likewise.
* gcc.dg/pie-6.c: Likewise.
---
gcc/testsuite/gcc.dg/pic-1.c | 2 +-
gcc/testsuite/gcc.dg/pic-3.c | 2 +-
gcc/testsuite/gcc.dg/pic-4.c | 2 +-
gcc/testsuite/gcc.dg/pie-1.c | 2 +-
gcc/testsuite/gcc.dg/pie-3.c | 2 +-
gcc/testsuite/gcc.dg/pie-4.c | 2 +-
gcc/testsuite/gcc.dg/pie-6.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/pic-1.c b/gcc/testsuite/gcc.dg/pic-1.c
index 7eb0765..86360aa 100644
--- a/gcc/testsuite/gcc.dg/pic-1.c
+++ b/gcc/testsuite/gcc.dg/pic-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! *-*-darwin* } } } */
/* { dg-options "-fpic" } */
#if __PIC__ != 1
diff --git a/gcc/testsuite/gcc.dg/pic-3.c b/gcc/testsuite/gcc.dg/pic-3.c
index d7d861b..7c4bbce 100644
--- a/gcc/testsuite/gcc.dg/pic-3.c
+++ b/gcc/testsuite/gcc.dg/pic-3.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! *-*-darwin* } } } */
/* { dg-options "-fno-pic" } */
#ifdef __PIC__
diff --git a/gcc/testsuite/gcc.dg/pic-4.c b/gcc/testsuite/gcc.dg/pic-4.c
index 732f61f..727fe14 100644
--- a/gcc/testsuite/gcc.dg/pic-4.c
+++ b/gcc/testsuite/gcc.dg/pic-4.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! *-*-darwin* } } } */
/* { dg-options "-fno-PIC" } */
#ifdef __PIC__
diff --git a/gcc/testsuite/gcc.dg/pie-1.c b/gcc/testsuite/gcc.dg/pie-1.c
index ff6281f..ca43e8b 100644
--- a/gcc/testsuite/gcc.dg/pie-1.c
+++ b/gcc/testsuite/gcc.dg/pie-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! *-*-darwin* } } } */
/* { dg-options "-fpie" } */
#if __PI
[PATCH]PR other/70268: map one directory name (old) to another (new) in __FILE__
Similar -fdebug-prefix-map, add option -ffile-prefix-map to map one
directory name (old) to another (new) in __FILE__, __BASE_FILE__ and
__builtin_FILE().
PR other/70268
* gcc/c-family/c.opt(-ffile-prefix-map=): New option.
* gcc/c-family/c-opts.c: Include file-map.h
(c_common_handle_option): Handle -ffile-prefix-map.
* gcc/gimplify.c: Include file-map.h
(gimplify_call_expr): Call remap_file_filename
* gcc/dwarf2out.c (gen_producer_string): Ignore -ffile-prefix-map.
* libcpp/macro.c: Include file-map.h
(_cpp_builtin_macro_text): Call remap_file_filename
* libcpp/include/file-map.h (remap_file_filename,
add_file_prefix_map): Declare.
* libcpp/file-map.c: Include config.h, system.h, file-map.h.
(struct file_prefix_map, file_prefix_maps, add_file_prefix_map,
remap_file_filename): New.
* libcpp/Makefile.in (file-map.c, file-map.o,
file-map.h): Update dependencies.
* doc/invoke.texi (-ffile-prefix-map): Document.
Signed-off-by: Hongxu Jia
---
gcc/ChangeLog | 9 +
gcc/c-family/c-opts.c | 6
gcc/c-family/c.opt| 4 +++
gcc/doc/invoke.texi | 6
gcc/dwarf2out.c | 1 +
gcc/gimplify.c| 2 ++
libcpp/ChangeLog | 12 +++
libcpp/Makefile.in| 10 +++---
libcpp/file-map.c | 92 +++
libcpp/include/file-map.h | 30
libcpp/macro.c| 2 ++
11 files changed, 169 insertions(+), 5 deletions(-)
create mode 100644 libcpp/file-map.c
create mode 100644 libcpp/include/file-map.h
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 68fcd05..d58f6ee 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2016-03-17 Hongxu Jia
+ PR **/**
+ * c-family/c-opts.c: Include file-map.h
+ (c_common_handle_option): Handle -ffile-prefix-map.
+ * c-family/c.opt(-ffile-prefix-map=): New option.
+ * gimplify.c: Include file-map.h
+ (gimplify_call_expr): Call remap_file_filename
+ * dwarf2out.c (gen_producer_string): Ignore -ffile-prefix-map.
+
2016-03-16 Carlos O'Donell
Sandra Loosemore
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index fec58bc..4dab155 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include "plugin.h"/* For PLUGIN_INCLUDE_FILE event. */
#include "mkdeps.h"
#include "dumpfile.h"
+#include "file-map.h"
#ifndef DOLLARS_IN_IDENTIFIERS
# define DOLLARS_IN_IDENTIFIERS true
@@ -503,6 +504,11 @@ c_common_handle_option (size_t scode, const char *arg, int
value,
cpp_opts->narrow_charset = arg;
break;
+case OPT_ffile_prefix_map_:
+ if (add_file_prefix_map(arg) < 0)
+error ("invalid argument %qs to -ffile-prefix-map", arg);
+ break;
+
case OPT_fwide_exec_charset_:
cpp_opts->wide_charset = arg;
break;
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 7c5f6c7..2b88874 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1204,6 +1204,10 @@ fexec-charset=
C ObjC C++ ObjC++ Joined RejectNegative
-fexec-charset= Convert all strings and character constants to
character set .
+ffile-prefix-map=
+C ObjC C++ ObjC++ Joined RejectNegative
+-ffile-prefix-map=Map one directory name to another in __FILE__,
__BASE_FILE__ and __builtin_FILE()
+
fextended-identifiers
C ObjC C++ ObjC++
Permit universal character names (\\u and \\U) in identifiers.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 99ac11b..d45d85f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -323,6 +323,7 @@ Objective-C and Objective-C++ Dialects}.
-gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf @gol
-gvms -gxcoff -gxcoff+ -gz@r{[}=@var{type}@r{]} @gol
-fdebug-prefix-map=@var{old}=@var{new} -fdebug-types-section @gol
+-ffile-prefix-map=@var{old}=@var{new} @gol
-feliminate-dwarf2-dups -fno-eliminate-unused-debug-types @gol
-femit-struct-debug-baseonly -femit-struct-debug-reduced @gol
-femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
@@ -5929,6 +5930,11 @@ link processing time. Merging is enabled by default.
When compiling files in directory @file{@var{old}}, record debugging
information describing them as in @file{@var{new}} instead.
+@item -ffile-prefix-map=@var{old}=@var{new}
+@opindex ffile-prefix-map
+When parsing __FILE__, __BASE_FILE__ and __builtin_FILE(), use directory
+@file{@var{new}} to replace @file{@var{old}}.
+
@item -fvar-tracking
@opindex fvar-tracking
Run variable tracking pass. It computes where variables are stored at each
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 61bf267..d8beeea 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -21672,6 +21672,7 @@ gen_producer_string (void)
case OPT_fltrans_output_list_:
case OPT_fresolution_:
case OPT_fdebug_prefix_map_:
+ case OPT_ffile_prefix_map_:
/* Ignore these. */
contin
