Ping**(5./7.) [patch, fortran] Implement maxval for characters
Am 28.11.2017 um 19:40 schrieb Thomas Koenig: Hello world, the attached patch implements maxval for characters, an F2003 feature that we were missing up to now. Regression-tested on x86_64-pc-linux-gnu. OK for trunk? Ping?
Re: [committed] Avoid -Wsurprising warning on OpenMP min/max array reductions (PR fortran/81304)
On Sat, Dec 02, 2017 at 03:14:31PM +0100, Janus Weil wrote: > thanks a lot for fixing this. Since it's a regression and the fix is > so trivial, I hope you're willing to backport it to the 6 and 7 > branches as well? (If not, I can also take care of that.) Yes, I'll be backporting lots of fixes of mine before 7.3 beta and afterwards will also do backports to 6. Jakub
Re: [PATCH 5/3] C++ bits to improve detection of attribute conflicts (PR 81544)
Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01034.html
The attached C++ only patch is rebased on the top of trunk.
The remaining patches in the series (C FE and the back ends)
have been approved.
Martin
On 08/23/2017 08:36 AM, Martin Sebor wrote:
On 08/22/2017 09:51 PM, Jason Merrill wrote:
The C and C++ front ends already have a diagnose_mismatched_attributes
function, which seems like the natural place to add more conflict
checking.
There are a few major problems with handling attribute conflicts
in diagnose_mismatched_attributes.
The function only diagnoses conflicts, it doesn't resolve them
(choose one attribute or the other). Currently, when they are
resolved, it's done in each attribute handler. But this is done
inconsistently because of the limitations of the infrastructure:
no access to the last pushed declaration. Often, it's not done
at all. Making the declaration available to every handler is
one of the design improvements of the patch.
Attributes are defined in the attribute_spec tables in a number
of different places: all the back ends, in addition to the front
ends, but processed by the general infrastructure in
decl_attributes in attribs.c. The infrastructure already has
all the smarts to either accept or reject a conflicting attribute.
None of this is available in diagnose_mismatched_attributes.
The current implementation of the function hardcodes knowledge
about a small number of attribute relationships in the code.
That's a poor approach given the table-driven attribute_spec
design. For one, it makes it difficult for back-end maintainers
to add a new attribute that's mutually exclusive with another
(the back-end maintainer would need to change the front end).
It might explain why no back-end attribute conflicts are
diagnosed there.
Some, maybe even most of these problems could be overcome by
moving the conflict resolution from decl_attributes to
diagnose_mismatched_attributes. But it would mean duplicating
a fair amount of the logic between the two functions. I think
that would result in an inferior solution. From both a design
and implementation point of view, I feel the logic fits best
in the attribs.c.
Martin
PR c/81544 - attribute noreturn and warn_unused_result on the same function accepted
gcc/cp/ChangeLog:
PR c/81544
* cp-tree.h (decls_match): Add default argument.
* decl.c (decls_match): Avoid calling into the target back end
and triggering an error.
* decl2.c (cplus_decl_attributes): Look up existing declaration and
pass it to decl_attributes.
* tree.c (cxx_attribute_table): Initialize new member of struct
attribute_spec.
gcc/testsuite/ChangeLog:
PR c/81544
* g++.dg/Wattributes-2.C: New test.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e77241f..736c484 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6116,7 +6116,7 @@ extern void note_break_stmt (void);
extern bool note_iteration_stmt_body_start (void);
extern void note_iteration_stmt_body_end (bool);
extern tree make_lambda_name (void);
-extern int decls_match(tree, tree);
+extern int decls_match(tree, tree, bool = true);
extern bool maybe_version_functions (tree, tree);
extern tree duplicate_decls (tree, tree, bool);
extern tree declare_local_label (tree);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 7085d5a..99b22dc 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -992,7 +992,7 @@ push_local_name (tree decl)
`const int&'. */
int
-decls_match (tree newdecl, tree olddecl)
+decls_match (tree newdecl, tree olddecl, bool record_versions /* = true */)
{
int types_match;
@@ -1087,6 +1087,7 @@ decls_match (tree newdecl, tree olddecl)
if (types_match
&& !DECL_EXTERN_C_P (newdecl)
&& !DECL_EXTERN_C_P (olddecl)
+ && record_versions
&& maybe_version_functions (newdecl, olddecl))
return 0;
}
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 13e7b1d..f20c54d 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1473,7 +1473,31 @@ cplus_decl_attributes (tree *decl, tree attributes, int flags)
attributes, flags);
}
else
-decl_attributes (decl, attributes, flags);
+{
+ tree last_decl = (DECL_P (*decl) && DECL_NAME (*decl)
+ ? lookup_name (DECL_NAME (*decl)) : NULL_TREE);
+
+ if (last_decl && TREE_CODE (last_decl) == OVERLOAD)
+ for (ovl_iterator iter (last_decl, true); ; ++iter)
+ {
+ if (!iter)
+ {
+ last_decl = NULL_TREE;
+ break;
+ }
+
+ if (TREE_CODE (*iter) == OVERLOAD)
+ continue;
+
+ if (decls_match (*decl, *iter, /*record_decls=*/false))
+ {
+ last_decl = *iter;
+ break;
+ }
+ }
+
+ decl_attributes (decl, attributes, flags, last_decl);
+}
if (TREE_CODE (*decl) == TYPE_DECL)
SET_IDENTIFIER_TYPE_VALUE (DECL_NAME (*decl), TREE_TYPE (*decl));
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index c76dea4..1ebee70 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4323,24 +4323,24 @@ handle_nodiscard_attrib
[patch, libgfortran] Bug 83191 - [7/8 Regression] Writing a namelist with repeated complex numbers
Hi all,
I plan to commit the attached patch with a test case shortly.
It is relatively simple. Thanks to Dominique for pinpointing the location right
away.
Regression tested on x86_64-pc-linux-gnu.
Regards,
Jerry
2017-12-03 Jerry DeLisle
Dominique d'Humieres
PR libgfortran/83191
* io/transfer.c (list_formatted_read_scalar): Do not set
namelist_mode bit here. (namelist_read): Likewise.
(data_transfer_init): Clear the mode bit here.
(finalize_transfer): Do set the mode bit just before any calls
to namelist_read or namelist_write. It can now be referred to
in complex_write.
^ io/write.c (write_complex): Suppress the leading blanks when
namelist_mode bit is not set to 1.
diff --git a/libgfortran/ChangeLog b/libgfortran/ChangeLog
index 1d4e62434ac..6e77d53961b 100644
--- a/libgfortran/ChangeLog
+++ b/libgfortran/ChangeLog
@@ -1,3 +1,7 @@
+2017-12-02 Jerry DeLisle
+
+ PR libgfortran/83191
+
2017-12-02 Jerry DeLisle
PR libgfortran/83225
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 3c03a02cad8..379050cecad 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2099,8 +2099,6 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p,
int c, i, m;
int err = 0;
- dtp->u.p.namelist_mode = 0;
-
/* Set the next_char and push_char worker functions. */
set_workers (dtp);
@@ -3546,7 +3544,6 @@ namelist_read (st_parameter_dt *dtp)
name. */
namelist_info *prev_nl = NULL;
- dtp->u.p.namelist_mode = 1;
dtp->u.p.input_complete = 0;
dtp->u.p.expanded_read = 0;
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 5429a855541..4d7ca7abf7b 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2671,7 +2671,7 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
dtp->u.p.ionml = ionml;
dtp->u.p.mode = read_flag ? READING : WRITING;
-
+ dtp->u.p.namelist_mode = 0;
dtp->u.p.cc.len = 0;
if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) != IOPARM_LIBRETURN_OK)
@@ -3890,6 +3890,7 @@ finalize_transfer (st_parameter_dt *dtp)
if ((dtp->u.p.ionml != NULL)
&& (cf & IOPARM_DT_HAS_NAMELIST_NAME) != 0)
{
+ dtp->u.p.namelist_mode = 1;
if ((cf & IOPARM_DT_NAMELIST_READ_MODE) != 0)
namelist_read (dtp);
else
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 582d196c4e3..926d510f4d7 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1809,9 +1809,11 @@ write_complex (st_parameter_dt *dtp, const char *source, int kind, size_t size)
precision, buf_size, result1, &res_len1);
get_float_string (dtp, &f, source + size / 2 , kind, 0, buffer,
precision, buf_size, result2, &res_len2);
- lblanks = width - res_len1 - res_len2 - 3;
-
- write_x (dtp, lblanks, lblanks);
+ if (!dtp->u.p.namelist_mode)
+{
+ lblanks = width - res_len1 - res_len2 - 3;
+ write_x (dtp, lblanks, lblanks);
+}
write_char (dtp, '(');
write_float_string (dtp, result1, res_len1);
write_char (dtp, semi_comma);
Re: [patch, wwwdocs, committed]
On Fri, 6 Oct 2017, Thomas Koenig wrote: > I just committed the change below. Gerald's bot had no > complaints, so I guess this must be OK :-) Yes, and generally when it comes to the web pages, better change than sorry (of missing something). :-) Well, don't break the main page I guess, but, really, having up-to-date and complete contents up is more important than the occasional minor markup error. So, thanks, and keep that up! Gerald
Re: [PATCH][i386,AVX] Enable VBMI2 support [5/7]
Hi Julia, hi Kirill, On Tue, 24 Oct 2017, Koval, Julia wrote: > This patch enables VPSHRD instruction. packing a "random" of your contributions. Can you please also think how to best document this in http://gcc.gnu.org/gcc-8/changes.html ? Let me know if you need any help with the web side of things (beyond the brief notes in https://gcc.gnu.org/about.html )! Gerald
[wwwdocs] Remove a final reference to libjava in bugs/
Applied. Gerald Index: bugs/reghunt.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/reghunt.html,v retrieving revision 1.20 diff -u -r1.20 reghunt.html --- bugs/reghunt.html 9 Jul 2014 00:03:06 - 1.20 +++ bugs/reghunt.html 3 Dec 2017 17:41:26 - @@ -94,7 +94,6 @@ --exclude=gcc-svn/boehm-gcc --exclude=gcc-svn/old-gcc --exclude=gcc-svn/wwwdocs ---exclude=gcc-svn/gcc/libjava --exclude=gcc-svn/gcc/libstdc++-v3 --exclude=gcc-svn/gcc/gcc/ada --exclude=gcc-svn/gcc/gcc/testsuite
Re: Ping**(5./7.) [patch, fortran] Implement maxval for characters
On 12/03/2017 01:48 AM, Thomas Koenig wrote: > Am 28.11.2017 um 19:40 schrieb Thomas Koenig: >> Hello world, >> >> the attached patch implements maxval for characters, an F2003 feature >> that we were missing up to now. >> >> Regression-tested on x86_64-pc-linux-gnu. >> >> OK for trunk? > > Ping? > Looks Good. OK. Thanks for patch, Jerry
Re: Ping**(5./7.) [patch, fortran] Implement maxval for characters
Am 03.12.2017 um 20:59 schrieb Jerry DeLisle: On 12/03/2017 01:48 AM, Thomas Koenig wrote: Am 28.11.2017 um 19:40 schrieb Thomas Koenig: Hello world, the attached patch implements maxval for characters, an F2003 feature that we were missing up to now. Regression-tested on x86_64-pc-linux-gnu. OK for trunk? Ping? Looks Good. OK. Committed as r255367. Thanks for the review! Regards Thomas
[v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr
Tested on Linux-x64.
2017-11-14 Ville Voutilainen
Implement LWG 2221
* include/std/ostream (operator<<(nullptr_t)): New.
* testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc: New.
diff --git a/libstdc++-v3/include/std/ostream b/libstdc++-v3/include/std/ostream
index f7cab03..18011bc 100644
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -245,6 +245,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator<<(const void* __p)
{ return _M_insert(__p); }
+#if __cplusplus > 201402L
+ __ostream_type&
+ operator<<(nullptr_t)
+ { return *this << "nullptr"; }
+#endif
+
/**
* @brief Extracting from another streambuf.
* @param __sb A pointer to a streambuf
diff --git
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc
new file mode 100644
index 000..1ffacb3
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc
@@ -0,0 +1,9 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do compile }
+
+#include
+
+int main()
+{
+ std::cout << nullptr << std::endl;
+}
[committed] hppa: Fix bootstrap on hppa-hpux
-- John David Anglin dave.ang...@bell.net
Re: [committed] hppa: Fix bootstrap on hppa-hpux
Sorry, hit wrong button. The attached patch fixes gcc bootstrap on hppa-hpux. Revision r254585 changed the handling of scaled-index addresses. We weren't checking the base operand to ensure that the REG_POINTER flag was set prior to load. As a result, we accepted invalid base register operands. The attached change fixes this problem. Dave -- John David Anglin dave.ang...@bell.net 2017-12-03 John David Anglin * config/pa/pa.c (pa_legitimate_address_p): For scaled indexing, require base operand is a REG_POINTER prior to reload on targets with non-equivalent space registers. Index: config/pa/pa.c === --- config/pa/pa.c (revision 254585) +++ config/pa/pa.c (working copy) @@ -10544,9 +10544,16 @@ if (!TARGET_DISABLE_INDEXING && GET_CODE (index) == MULT - && MODE_OK_FOR_SCALED_INDEXING_P (mode) + /* Only accept base operands with the REG_POINTER flag prior to +reload on targets with non-equivalent space registers. */ + && (TARGET_NO_SPACE_REGS + || (base == XEXP (x, 1) + && (reload_completed + || (reload_in_progress && HARD_REGISTER_P (base)) + || REG_POINTER (base && REG_P (XEXP (index, 0)) && GET_MODE (XEXP (index, 0)) == Pmode + && MODE_OK_FOR_SCALED_INDEXING_P (mode) && (strict ? STRICT_REG_OK_FOR_INDEX_P (XEXP (index, 0)) : REG_OK_FOR_INDEX_P (XEXP (index, 0))) && GET_CODE (XEXP (index, 1)) == CONST_INT
Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
Dear Paul, > Bootstrapped and regtested on FC23/x86_64 - OK for trunk? See my comment 7 in the PR. Dominique
[PATCH] enhance documentation of -Wstringop-truncation
It was suggested to me that it might be helpful to mention
attribute nonstring as a solution to -Wstringop-truncation
warnings. I think it's a good idea to add a reference to
the attribute to the manual. The attached patch does that.
Since the attribute is suitable only under rare conditions
suggesting it in the text of the diagnostics (e.g., in the
form of a note) would unlikely be useful (and, if acted on,
could even lead to other kinds of warnings) so I opted not
to make such a change.
Martin
2017-12-03 Martin Sebor
* doc/invoke.texi (-Wstringop-truncation): Mention attribute nonstring.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 255369)
+++ gcc/doc/invoke.texi (working copy)
@@ -5256,6 +5256,14 @@ void copy (const char *s)
@}
@end smallexample
+In situations where a character array is intended to store a sequence
+of bytes with no terminating @code{NUL} such an array may be annotated
+with attribute @code{nonstring} to avoid this warning. Such arrays,
+however, are not suitable arguments to functions that expect
+@code{NUL}-terminated strings. To help detect accidental misuses of
+such arrays, GCC issues warnings unless it can prove that the use is
+safe. @xref{Common Variable Attributes}.
+
@item -Wsuggest-attribute=@r{[}pure@r{|}const@r{|}noreturn@r{|}format@r{|}cold@r{|}malloc@r{]}
@opindex Wsuggest-attribute=
@opindex Wno-suggest-attribute=
Re: [PATCH] lra: Clobbers in a parallel are earlyclobbers (PR83245)
On 12/02/2017 01:59 PM, Segher Boessenkool wrote:
The documentation (rtl.texi) says:
When a @code{clobber} expression for a register appears inside a
@code{parallel} with other side effects, the register allocator
guarantees that the register is unoccupied both before and after that
insn if it is a hard register clobber.
and at least the rs6000 backend relies on that (see PR83245). This
patch restores that behaviour.
Registers that are also used as operands in the instruction are not
treated as earlyclobber, so such insns also still work (PR80818, an
s390 testcase).
Tested on powerpc64-linux {-m32,-m64}, also tested with a s390 cross.
Andreas, can you confirm this really still works after this patch?
Vlad, if so, is this okay for trunk?
Yes, it is ok for me in any case, even if it creates a trouble for s390
PR80818. Sorry for the inconvenience from my patch. I should have been
more careful.
[RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes
As we touched on in IRC, the EVRP analyzer was doing something stupid
which caused it to not merge in existing range information under certain
circumstances.
Consider this fragment:
x_1 = foo ()
if (x_1 > 2)
__builtin_unreachable ();
if (x_1 < 0)
__builtin_unreachable ();
Obviously the range for x_1 is [0,2] and we compute that range in the
EVRP optimization pass as well as VRP.
If a pass (say VRP) were to delete the __builtin_unreachable calls we'll
be left with:
x_1 = foo ()
Any subsequent EVRP analysis won't be able to generate range information
for that statement -- ie, it looks like VR_VARYING. Due to a dumb bug
in the EVRP analysis we allowed that VR_VARYING to override any range
that had been computed by an earlier VRP or EVRP pass.
Fixing is trivial. Always call update_value_range, even if the
currently discovered range is VR_VARYING.
Bootstrapped and regression tested, both in isolation and as part of
this 3 part kit.
OK for the trunk?
Jeff
* gimple-ssa-evrp-analyze.c
(evrp_range_analyzer::extract_range_from_stmt): Always use
vr_values::update_value_range so preexisting range info is
medged with new range info, even if the new range is VR_VARYING.
diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 551b1d6..fb3d329 100644
--- a/gcc/gimple-ssa-evrp-analyze.c
+++ b/gcc/gimple-ssa-evrp-analyze.c
@@ -271,8 +271,7 @@ evrp_range_analyzer::record_ranges_from_stmt (gimple *stmt)
edge taken_edge;
value_range vr = VR_INITIALIZER;
vr_values->extract_range_from_stmt (stmt, &taken_edge, &output, &vr);
- if (output
- && (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE))
+ if (output)
{
vr_values->update_value_range (output, &vr);
[RFA][PATCH][tree-optimization/78496] 02/03 Do not exploit __builtin_unreachable if -fsanitize=unreachable
As I brought my patches for pr78496 up to the tip of the trunk I noticed a couple testsuite regressions with -fsanitize=unreachable tests. The problem is VRP and EVRP analysis/optimization could exploit __builtin_unreachable to narrow the range of an object, then use that narrowed range to eliminate the __builtin_unreachable. That seems fundamentally wrong if we're compiling with -fsanitize=unreachable. So this patch changes both to not exploit __builtin_unreachable when -fsanitize=unreachable. Bootstrapped and regression tested with all three patches in this kit. OK for the trunk? Jeff * gimple-ssa-evrp-analyze.c (evrp_range_analyzer::record_ranges_from_incoming_edge): Do not exploit __builtin_unreachable for -fsanitize=unreachable. * tree-vrp.c (remove_range_assertions): Similarly. diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c index fb3d329..3cdf271 100644 --- a/gcc/gimple-ssa-evrp-analyze.c +++ b/gcc/gimple-ssa-evrp-analyze.c @@ -193,7 +193,8 @@ evrp_range_analyzer::record_ranges_from_incoming_edge (basic_block bb) /* If pred_e is really a fallthru we can record value ranges in SSA names as well. */ - bool is_fallthru = assert_unreachable_fallthru_edge_p (pred_e); + bool is_fallthru = (assert_unreachable_fallthru_edge_p (pred_e) + && (flag_sanitize & SANITIZE_UNREACHABLE) == 0); /* Push updated ranges only after finding all of them to avoid ordering issues that can lead to worse ranges. */ diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index a86b382..d0435a0 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -5181,7 +5181,8 @@ remove_range_assertions (void) is_unreachable = 0; if (single_pred_p (bb) && assert_unreachable_fallthru_edge_p - (single_pred_edge (bb))) + (single_pred_edge (bb)) + && (flag_sanitize & SANITIZE_UNREACHABLE) == 0) is_unreachable = 1; } /* Handle
[RFA][PATCH][tree-optimization/78496] 03/03 Embed and exploit EVRP analysis within DOM
And finally, the meat of the fix for pr78496. This is largely the patch
that was posed right when stage1 closed with just minor updates.
This patch embeds evrp analysis into DOM and exploits it in the minimal
way necessary to fix pr78496 without regressing other tests in the
testsuite.
The key effect we're looking for here is to pick up a slew of jump
threads in DOM2 by exploiting the range information during jump threading.
These aren't handled well in the standard tree-vrp jump threading -- we
could abuse ASSERT_EXPRs further, but it'd just be ugly and probably
computationally expensive.
The ranges we want fall out naturally from a dominator walk, hence all
the recent work around pulling out EVRP analysis into a little module
other passes could reuse.
With these changes we pick up all the missing jump thread opportunities
in DOM for pr78496. Sadly, I've been able to pull together an automated
test that I like. About the best I could come up with would be to
verify that a large number of jump threads were realized during DOM2.
But that still seems rather fragile. I also looked at examining the
results of PRE, but the partial redundancies that were originally the
source of complaints in that BZ have already been fixed. I also looked
at perhaps looking for PHIs with constant args and then perhaps trying
to filter those, but got nowhere.
So there's no direct test for pr78496. Sigh.
Running EVRP analysis in DOM had an unintended side effect. Namely that
SSA_NAMEs that got created after the EVRP optimization pass would have
range information attached to them. That caused two warning regressions
with -O1 code in the C++ and Fortran testsuites. The problem is the
ranges attached to the new SSA_NAMES were very wide and there was code
left on an unexecutable path that called an allocation routine (C++) and
a memset (Fortran) using those names as arguments. The uber-wide ranges
in those circumstances triggered the false positive warnings.
By exploiting the EVRP data during the standard part of DOM to optimize
conditionals, we're able to prove the paths in question simply aren't
executable. We remove them and the warnings go away.
This work compromises builtin-unreachable-6. So the original test it
kept and -fno-tree-dominator-opts is added to keep it from being
compromised. A new builtin-unreachable-6a test is created to very that
DOM does indeed remove all the __builtin_unreachable paths.
This work also results in us optimizing 20030922-2.c again (conditional
equivalences). EVRP analysis will note the conditional equivalence. We
don't propagate anything from EVRP analysis at this time, but we do use
it to try and simplify GIMPLE_CONDs to a compile-time constant which is
what happens in this case.
I plan to check this in if/when the first two patches are approved.
Jeff
ps. The x_vr_values hack is scheduled to go away as we remove
tree-vrp.c's threading implementation in gcc-9 -- we'll be able to drop
the simplification callback and instead have simplification live within
the dom_opt_dom_walker class where it'll have access to vr_values. The
analogous version in tree-vrp.c just gets deleted at that time.
pps. I know there's a bogus propagation patch that I need to go back and
re-check based on comments from Richi. That's definitely in the queue.
* gimple-ssa-evrp-analyze.h
(evrp_range_analyzer::get_vr_values): Simplify.
* gimple-ssa-evrp-analyze.c: Corresponding changes.
* tree-ssa-dom.c: Include alloc-pool.h, tree-vrp.h, vr-values.h
and gimple-ssa-evrp-analyze.h.
(dom_opt_dom_walker class): Add evrp_range_analyzer member.
(simplify_stmt_for_jump_threading): Copy a blob of code from
tree-vrp.c to use ranges to simplify statements.
(dom_opt_dom_walker::before_dom_children): Call
evrp_range_analyzer::{enter,record_ranges_from_stmt} methods.
(dom_opt_dom_walker::after_dom_children): Similarly for
evrp_range_analyzer::leave.
(dom_opt_dom_walker::optimize_stmt): Use EVRP ranges to optimize
conditionals.
* gcc.dg/builtin-unreachable-6.c: Disable DOM.
* gcc.dg/builtin-unreachable-6a.c: New test.
* gcc.dg/tree-ssa/20030922-1.c: No longer XFAIL.
* gcc.dg/ssa-dom-branch-1.c: Tweak expected output.
diff --git a/gcc/gimple-ssa-evrp-analyze.h b/gcc/gimple-ssa-evrp-analyze.h
index 6216a90..4783e6f 100644
--- a/gcc/gimple-ssa-evrp-analyze.h
+++ b/gcc/gimple-ssa-evrp-analyze.h
@@ -51,13 +51,7 @@ class evrp_range_analyzer
true, then we are transferring ownership. Else we keep ownership.
This should be converted to a unique_ptr. */
- class vr_values *get_vr_values (bool transfer)
-{
- class vr_values *x = vr_values;
- if (transfer)
- vr_values = NULL;
- return x;
-}
+ class vr_values *get_vr_values (void) { return vr_values; }
private:
DISABLE_COPY_AND_ASSIGN (evrp_range_analyzer);
diff --git a/gcc/gi
[testsuite, committed] Require effective target alloca for pr82875.c
[ was: Re: [PATCH] Fix mult expansion ICE (PR middle-end/82875) ]
On 11/22/2017 10:17 AM, Jakub Jelinek wrote:
--- gcc/testsuite/gcc.dg/pr82875.c.jj 2017-11-21 17:50:16.022274628 +0100
+++ gcc/testsuite/gcc.dg/pr82875.c 2017-11-21 17:49:46.0 +0100
@@ -0,0 +1,11 @@
+/* PR middle-end/82875 */
+/* { dg-do compile } */
+/* { dg-options "-ftree-ter" } */
+
+const int a = 100;
+
+void
+foo (void)
+{
+ int c[a];
+}
Hi,
this patch requires effective target alloca for pr82875.c.
Committed.
Thanks,
- Tom
Require effective target alloca for pr82875.c
2017-12-04 Tom de Vries
* gcc.dg/pr82875.c: Require effective target alloca.
---
gcc/testsuite/gcc.dg/pr82875.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/pr82875.c b/gcc/testsuite/gcc.dg/pr82875.c
index 5b97b80..52f1de7 100644
--- a/gcc/testsuite/gcc.dg/pr82875.c
+++ b/gcc/testsuite/gcc.dg/pr82875.c
@@ -1,6 +1,7 @@
/* PR middle-end/82875 */
/* { dg-do compile } */
/* { dg-options "-ftree-ter" } */
+/* { dg-require-effective-target alloca } */
const int a = 100;
RE: [PATCH][i386,AVX] Enable VBMI2 support [5/7]
Hi Gerald, Do you think it is ok to copypaste it from GCC-6? GCC now supports the Intel CPU, named Cannonlake through -march=cannonlake. The switch enables the following ISA extensions: AVX512VBMI, AVX512IFMA, SHA. GCC now supports the Intel CPU, named and Icelake through -march=icelake. The switch enables the following ISA extensions: AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ. Thanks, Julia > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Gerald Pfeifer > Sent: Sunday, December 03, 2017 6:51 PM > To: Koval, Julia ; Kirill Yukhin > > Cc: GCC Patches > Subject: Re: [PATCH][i386,AVX] Enable VBMI2 support [5/7] > > Hi Julia, hi Kirill, > > On Tue, 24 Oct 2017, Koval, Julia wrote: > > This patch enables VPSHRD instruction. > > packing a "random" of your contributions. Can you please also think > how to best document this in http://gcc.gnu.org/gcc-8/changes.html ? > > Let me know if you need any help with the web side of things (beyond > the brief notes in https://gcc.gnu.org/about.html )! > > Gerald
