[PATCH, wwwdocs] Update cxx-status.html
Hi! The following patch adds C++2a stuff to cxx-status.html (list of papers from clang table, filled in what has notes in cp/ChangeLog-2017 + __VA_OPT__). For C++17 features I've just added a couple of / markings and added the second deduction guides paper (P0512R0), plus mentioned that the standard has been published already. Ok to commit? C++17 support is still marked experimental, do we want to keep it that way for GCC 8, or change that? Are there any known feature macros for the C++2a features, or is that still WIP? --- htdocs/projects/cxx-status.html.jj 2018-03-23 19:36:46.146783821 +0100 +++ htdocs/projects/cxx-status.html 2018-03-23 20:33:04.528598450 +0100 @@ -15,6 +15,7 @@ C++11 C++14 C++17 +C++2a Technical Specifications @@ -22,10 +23,148 @@ https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html";>this page. - C++17 Support in GCC + C++2a Support in GCC GCC has experimental support for the next revision of the C++ - standard, which is expected to be published in 2017. + standard, which is expected to be published in 2020. + + C++2a features are available as part of "mainline" GCC +in the trunk of GCC's repository +and will be available in GCC 8 and later. To enable C++2a + support, add the command-line parameter -std=c++2a + to your g++ command line. Or, to enable GNU + extensions in addition to C++2a features, +add -std=gnu++2a. + + Important: Because the ISO C++2a standard is + still evolving, GCC's support is experimental. No attempt + will be made to maintain backward compatibility with implementations of + C++2a features that do not reflect the final standard. + + C++2a Language Features + + The following table lists new language features that have been + accepted into the C++2a working draft. The "Proposal" column + provides a link to the ISO C++ committee proposal that describes the + feature, while the "Available in GCC?" column indicates the first + version of GCC that contains an implementation of this feature (if + it has been implemented). + + + + Language Feature + Proposal + Available in GCC? + SD-6 Feature Test + + + Default member initializers for bit-fields + http://wg21.link/p0683r1";>P0683R1 + 8 + + + + Fixing const-qualified pointers to members + http://wg21.link/p0704r1";>P0704R1 + 8 + + + + Allow lambda capture [=, this] + http://wg21.link/p0409r2";>P0409R2 + 8 + + + + __VA_OPT__ for preprocessor comma elision + http://wg21.link/p0306r4";>P0306R4 + 8 (partial, no #__VA_OPT__ support) + + + + Designated initializers + http://wg21.link/p0329r4";>P0329R4 + 8 + + + + Familiar template syntax for generic lambdas + http://wg21.link/p0428r2";>P0428R2 + 8 + + + + List deduction of vector + http://wg21.link/p0702r1";>P0702R1 + 8 + + + + Concepts + http://wg21.link/p0734r0";>P0734R0 +http://wg21.link/p0857r0";>P0857R0 + + + + + Range-based for statements with initializer + http://wg21.link/p0614r1";>P0614R1 + + + + + Simplifying implicit lambda capture + http://wg21.link/p0588r1";>P0588R1 + 8 + + + ADL and function templates that are not visible + http://wg21.link/p0846r0";>P0846R0 + + + + + const mismatch with defaulted copy constructor + http://wg21.link/p0641r2";>P0641R2 + + + + + Less eager instantiation of constexpr functions + http://wg21.link/p0859r0";>P0859R0 + + + + + Consistent comparison (operator<=>) + http://wg21.link/p0515r3";>P0515R3 + + + + + Access checking on specializations + http://wg21.link/p0692r1";>P0692R1 + + + + + Default constructible and assignable stateless lambdas + http://wg21.link/p0624r2";>P0624R2 + + + + + Lambdas in unevaluated contexts + http://wg21.link/p0315r4";>P0315R4 + + + + + + C++17 Support in GCC + + GCC has experimental support for the latest revision of the C++ + standard, which was published in 2017. C++17 features are available as part of "mainline" GCC in the trunk of GCC's repository @@ -96,7 +235,7 @@ __cpp_nontype_template_args >= 201411 - Extending static_assert + Extending static_assert http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf";>N3928 6 __cpp_static_assert >= 201411 @@ -114,24 +253,24 @@ - [[fallthrough]] attribute + [[fallthrough]] attribute http://www.open-std.org/jtc1/sc22/wg2
Re: RFC: Disable asan tests under ulimit -v
On Mär 23 2018, Jason Merrill wrote:
> diff --git a/gcc/testsuite/g++.dg/asan/asan.exp
> b/gcc/testsuite/g++.dg/asan/asan.exp
> index 4ee8dd98697..a22d2ac5e20 100644
> --- a/gcc/testsuite/g++.dg/asan/asan.exp
> +++ b/gcc/testsuite/g++.dg/asan/asan.exp
> @@ -24,6 +24,13 @@ load_lib asan-dg.exp
> dg-init
> asan_init
>
> +# asan doesn't work if there's a ulimit on virtual memory.
> +if ![is_remote target] {
> +if [regexp {^[0-9]+$} "[exec ulimit -v]"] {
Does that actually work? ulimit is a shell builtin, but exec does not
use the shell. Also, you get an error if the command returns a non-zero
status, or isn't found.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Use SCEV information when aligning for vectorisation (PR 84005)
Richard Biener writes:
> On Tue, Mar 20, 2018 at 4:26 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
> wrote:
>> Index: gcc/tree-data-ref.c
>> ===
>> --- gcc/tree-data-ref.c 2018-02-14 13:14:36.268006810 +
>> +++ gcc/tree-data-ref.c 2018-03-17 10:43:42.544669549 +
>> @@ -5200,6 +5200,75 @@ dr_alignment (innermost_loop_behavior *d
>>return alignment;
>> }
>>
>> +/* If BASE is a pointer-typed SSA name, try to find the object that it
>> + is based on. Return this object X on success and store the alignment
>> + in bytes of BASE - &X in *ALIGNMENT_OUT. */
>> +
>> +static tree
>> +get_base_for_alignment_1 (tree base, unsigned int *alignment_out)
>> +{
>> + if (TREE_CODE (base) != SSA_NAME || !POINTER_TYPE_P (TREE_TYPE
>> (base)))
>> +return NULL_TREE;
>> +
>> + gimple *def = SSA_NAME_DEF_STMT (base);
>> + base = analyze_scalar_evolution (loop_containing_stmt (def), base);
>
> I think it is an error to use the def stmt of base here. Instead you
> need to pass down the point/loop of the use. For the same reason you
> also want to instantiate parameters after analyzing the evolution.
>
> In the end, if the BB to be vectorized is contained in a loop nest
> we want to
> instantiate up to the point where (eventually) a DECL we can re-align
> appears,
> but using the containing loop for now looks OK.
Why's that necessary/better though? We're not interested in the
evolution of the value at the point it*s used by the potential vector
code, but in how we get from the ultimate base (if there is one) to the
definition of the SSA name.
>>>
>>> Hmm, ok.
>>>
I don't think instantiating the SCEV would give any new information,
but it could lose some. E.g. if we have:
x = &foo;
do
x += 8;
while (*y++ < 10)
...potential vector use of *x...
we wouldn't be able to express the address of x after the do-while
loop, because there's nothing that counts the number of iterations.
But the uninstantiated SCEV could tell us that x = &foo + N * 8 for
some (unknown) N.
>>>
>>> Not sure that it works that way. I'm not 100% sure what kind of
>>> parameters are left symbolic, and if analysis loop and instantiation
>>> "loop" are the same I guess it doesn't make any difference...
>>>
(OK, so that doesn't actually work unless we take the effort
to look through loop-closed SSA form, but still...)
>> + /* Peel chrecs and record the minimum alignment preserved by
>> + all steps. */
>> + unsigned int alignment = MAX_OFILE_ALIGNMENT / BITS_PER_UNIT;
>> + while (TREE_CODE (base) == POLYNOMIAL_CHREC)
>> +{
>> + unsigned int step_alignment = highest_pow2_factor (CHREC_RIGHT
>> (base));
>> + alignment = MIN (alignment, step_alignment);
>> + base = CHREC_LEFT (base);
>> +}
>> +
>> + /* Punt if the expression is too complicated to handle. */
>> + if (tree_contains_chrecs (base, NULL) || !POINTER_TYPE_P (TREE_TYPE
>> (base)))
>> +return NULL_TREE;
>> +
>> + /* Analyze the base to which the steps we peeled were applied. */
>> + poly_int64 bitsize, bitpos, bytepos;
>> + machine_mode mode;
>> + int unsignedp, reversep, volatilep;
>> + tree offset;
>> + base = get_inner_reference (build_fold_indirect_ref (base),
>
> ick :/
>
> what happens if you simply use get_pointer_alignment here and
> strip down POINTER_PLUS_EXPRs to the ultimate LHS? (basically
> what get_pointer_alignment_1 does) After all get_base_for_alignment_1
> itself only deals with plain SSA_NAMEs, not, say, &a_1->b.c or
> &MEM[a_1 + 4].
Yeah, but those have (hopefully) been handled by dr_analyze_innermost
already, which should have stripped off both the constant and variable
parts of the offset. So I think SSA names are the only interesting
input. The problem is that once we follow the definitions of an SSA
name through CHREC_LEFTs, we get a general address again.
get_pointer_alignment and get_pointer_alignment_1 don't do what we want
because they take the alignment of the existing object into account,
whereas here we explicitly want to ignore that and only calculate the
alignment of the offset.
>>>
>>> Ah, indeed - I missed that fact.
>>>
I guess we could pass a flag down to ignore the current alignment though?
>>>
>>> But we need the base anyway... so, given we can only ever re-align decls
>>> and never plain pointers instead of using build_fold_indirect_ref do
>>>
>>> if (T
C++ PATCH for c++/85032, rejects-valid with if constexpr in template
Recently the code in finish_static_assert was changed to use
perform_implicit_conversion_flags followed by fold_non_dependent_expr. That
broke this test becase when in a template, p_i_c_f merely wraps the expr in
an IMPLICIT_CONV_EXPR. fold_non_dependent_expr should be able to fold it to
a constant but it gave up because is_nondependent_constant_expression returned
false. Jason suggested to fix this roughly like the following, i.e. consider
conversions from classes to literal types potentially constant.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-24 Marek Polacek
PR c++/85032
* constexpr.c (potential_constant_expression_1): Consider conversions
from classes to literal types potentially constant.
* g++.dg/cpp0x/pr51225.C: Adjust error message.
* g++.dg/cpp1z/constexpr-if17.C: New test.
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index bebd9f5b5d0..c4b5afe90a2 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -5768,6 +5768,23 @@ potential_constant_expression_1 (tree t, bool want_rval,
bool strict, bool now,
TREE_TYPE (t));
return false;
}
+ /* This might be a conversion from a class to a literal type. Let's
+consider it potentially constant since the conversion might be
+a constexpr user-defined conversion. */
+ else if (cxx_dialect >= cxx11
+ && COMPLETE_TYPE_P (TREE_TYPE (t))
+ && literal_type_p (TREE_TYPE (t))
+ && TREE_OPERAND (t, 0))
+ {
+ tree type = TREE_TYPE (TREE_OPERAND (t, 0));
+ /* If this is a dependent type, it could end up being a class
+with conversions. */
+ if (type == NULL_TREE || WILDCARD_TYPE_P (type))
+ return true;
+ /* Or a non-dependent class which has conversions. */
+ else if (CLASS_TYPE_P (type) && TYPE_HAS_CONVERSION (type))
+ return true;
+ }
return (RECUR (TREE_OPERAND (t, 0),
TREE_CODE (TREE_TYPE (t)) != REFERENCE_TYPE));
diff --git gcc/testsuite/g++.dg/cpp0x/pr51225.C
gcc/testsuite/g++.dg/cpp0x/pr51225.C
index f80bd0e778e..5b4e432f7ed 100644
--- gcc/testsuite/g++.dg/cpp0x/pr51225.C
+++ gcc/testsuite/g++.dg/cpp0x/pr51225.C
@@ -5,7 +5,7 @@ template struct A {};
template void foo()
{
- A a; // { dg-error "not declared|invalid type" }
+ A a; // { dg-error "not declared|could not convert" }
}
template struct bar
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C
gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C
index e69de29bb2d..56e108be4ad 100644
--- gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if17.C
@@ -0,0 +1,22 @@
+// PR c++/85032
+// { dg-options -std=c++17 }
+
+struct A
+{
+ constexpr operator bool () { return true; }
+ int i;
+};
+
+A a;
+
+template
+void f()
+{
+ constexpr bool b = a;
+ static_assert (a);
+}
+
+int main()
+{
+ f();
+}
Marek
[patch, fortran] Fix empty substrings when simplifying
Hell world,
the attached patch is fairly self-explanatory, it fixes an out-of-memory
condition.
Regression-tested. OK for trunk?
Regards
Thomas
2018-03-24 Thomas Koenig
PR fortran/70068
* expr.c (find_substring_ref): Change types of start, end
and length variables to gfc_charlen_t. Set length to zero
for empty substring.
2018-03-24 Thomas Koenig
PR fortran/70068
* gfortran.dg/substr_7.f90: New test.
Index: expr.c
===
--- expr.c (revision 258501)
+++ expr.c (working copy)
@@ -1662,9 +1662,9 @@ cleanup:
static bool
find_substring_ref (gfc_expr *p, gfc_expr **newp)
{
- int end;
- int start;
- int length;
+ gfc_charlen_t end;
+ gfc_charlen_t start;
+ gfc_charlen_t length;
gfc_char_t *chr;
if (p->ref->u.ss.start->expr_type != EXPR_CONSTANT
@@ -1674,9 +1674,12 @@ find_substring_ref (gfc_expr *p, gfc_expr **newp)
*newp = gfc_copy_expr (p);
free ((*newp)->value.character.string);
- end = (int) mpz_get_ui (p->ref->u.ss.end->value.integer);
- start = (int) mpz_get_ui (p->ref->u.ss.start->value.integer);
- length = end - start + 1;
+ end = (gfc_charlen_t) mpz_get_ui (p->ref->u.ss.end->value.integer);
+ start = (gfc_charlen_t) mpz_get_ui (p->ref->u.ss.start->value.integer);
+ if (end >= start)
+length = end - start + 1;
+ else
+length = 0;
chr = (*newp)->value.character.string = gfc_get_wide_string (length + 1);
(*newp)->value.character.length = length;
! { dg-do run }
! PR 70068 - used to allocate too much memory
! Original test cases by Gerhard Steinmetz
program p
integer :: i
character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz']
character(3) :: y(2)
character(99), parameter :: x2(2) = ' '
character(99), parameter :: y2=x(2)(99:1)
y = [(x(i)(i:1), i=2,3)]
if (any(y /= '')) call abort
if (y2 /= '') call abort
end
Re: [patch, fortran] Fix empty substrings when simplifying
On 03/24/2018 05:46 AM, Thomas Koenig wrote: Hell world, the attached patch is fairly self-explanatory, it fixes an out-of-memory condition. Regression-tested. OK for trunk? Yes, and thanks for fix. Jerry
Re: [patch, fortran] Fix empty substrings when simplifying
On Sat, Mar 24, 2018 at 01:46:43PM +0100, Thomas Koenig wrote: > program p >integer :: i >character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz'] >character(3) :: y(2) >character(99), parameter :: x2(2) = ' ' >character(99), parameter :: y2=x(2)(99:1) >y = [(x(i)(i:1), i=2,3)] >if (any(y /= '')) call abort stop 1 >if (y2 /= '') call abort stop 2 > end Jerry already OK the patch. it you have committed yet, you might want to update the test. -- Steve
Re: [PATCH] Fix PR84986
On Tue, Mar 20, 2018 at 3:08 AM, Richard Biener wrote: > > With the x86 vectorizer cost-model rewrite we ended up costing > scalar conversions as nothing. After my patch using the proper > target cost estimates for the scalar version this now exposes > underestimating scalar cost and thus no longer vectorizing > the testcase in this PR. This fix is to restrict zero-costing > to sign-conversions, all other conversions are possibly > value-changing. I guess some zero-extensions are free as well > but I didn't want to get too fancy as I'm not sure about > QImode -> SImode conversions for example since whether > that's free (can just use %eax instead of %ax) likely depends on > context. > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. > > OK? > > Thanks, > Richard. > > 2018-03-20 Richard Biener > > PR target/84986 > * config/i386/i386.c (ix86_add_stmt_cost): Only cost > sign-conversions as zero, fall back to standard scalar_stmt > cost for the rest. > > * gcc.dg/vect/costmodel/x86_64/costmodel-pr84986.c: New testcase. > The test failed for -mx32: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85066 -- H.J.
Re: [patch, fortran] Fix empty substrings when simplifying
Am 24.03.2018 um 16:18 schrieb Jerry DeLisle: On 03/24/2018 05:46 AM, Thomas Koenig wrote: Hell world, the attached patch is fairly self-explanatory, it fixes an out-of-memory condition. Regression-tested. OK for trunk? Yes, and thanks for fix. Committed as r258835, with Steve's observation of using stop instead of call abort. I, of all people, should know, but old habits die hard :-) Regards Thomas
Re: [PATCH]Correct comment for ADDR_EXPR tree code.
Hi Jeff, On 23/03/18 23:19, Jeff Law wrote: On 03/23/2018 09:44 AM, Renlin Li wrote: Hi all, This is a simple patch to correct the comment for ADDR_EXPR tree code. The resulting expression of ADDR_EXPR is a tree with POINTER_TYPE. So the result mode should ptr_mode instead of Pmode. As far as I understand, Pmode is the addressing mode. But not the mode to represent a pointer (or address?). Okay to commit? Regards, Renlin gcc/ChangeLog: 2018-03-23 Renlin Li * tree.def (ADDR_EXPR): Correct the commnet.I'm not sure this is strictly correct. More importantly, I'm not sure why we care :-0 Modes are more of a target/RTL issue. Why a tree node needs to specify a mode in this case vs a type seems to be the more important question. It is a very minor issue, I just come cross the comment which doesn't seem very right. I agree, the type is more meaningful than the machine mode to describe a tree node. The result of ADDR_EXPR should be an expression of POINTER_TYPE or REFERENCE_TYPE as the document indicates. I can replace the sentence "Result mode is Pmode." with "The result expression will always have pointer or reference type." Thanks! Renlin jeff
[patch,fortran] Bug 69497 - ICE in gfc_free_namespace
This one has been hanging around for a while. Dominique found this fix. I retested with the 30 cases provided in the PR. These are all invalid fortran. They give errors now and do not ICE. Regression tested on trunk. OK? Jerry PS I will use the first of the many test cases for the testsuite with appropriate ChangeLog, etc. 2018-03-24 Jerry DeLisle Dominique d'Humieres PR fortran/84506 * symbol.c (gfc_free_namespace): Delete the assert and if refs count is less than zero, free the namespece. Something is halfway and other errors will resound. diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index ce6b1e93644..997d90b00fd 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -4037,10 +4037,9 @@ gfc_free_namespace (gfc_namespace *ns) return; ns->refs--; - if (ns->refs > 0) -return; - gcc_assert (ns->refs == 0); + if (ns->refs != 0) +return; gfc_free_statements (ns->code);
Re: [patch,fortran] Bug 69497 - ICE in gfc_free_namespace
On Sat, Mar 24, 2018 at 02:25:36PM -0700, Jerry DeLisle wrote: > > 2018-03-24 Jerry DeLisle > Dominique d'Humieres > > PR fortran/84506 > * symbol.c (gfc_free_namespace): Delete the assert and if refs > count is less than zero, free the namespece. Something is > halfway and other errors will resound. > > diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c > index ce6b1e93644..997d90b00fd 100644 > --- a/gcc/fortran/symbol.c > +++ b/gcc/fortran/symbol.c > @@ -4037,10 +4037,9 @@ gfc_free_namespace (gfc_namespace *ns) > return; > > ns->refs--; > - if (ns->refs > 0) > -return; > > - gcc_assert (ns->refs == 0); > + if (ns->refs != 0) > +return; > > gfc_free_statements (ns->code); The ChangeLog doesn't seem to match the patch. If ns->refs==0, you free the namespace. If ns->refs!=0, you return. So, if ns->refs<0, the namespace is not freed. -- Steve
Re: [patch,fortran] Bug 69497 - ICE in gfc_free_namespace
On 03/24/2018 02:56 PM, Steve Kargl wrote: On Sat, Mar 24, 2018 at 02:25:36PM -0700, Jerry DeLisle wrote: 2018-03-24 Jerry DeLisle Dominique d'Humieres PR fortran/84506 * symbol.c (gfc_free_namespace): Delete the assert and if refs count is less than zero, free the namespece. Something is halfway and other errors will resound. diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index ce6b1e93644..997d90b00fd 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -4037,10 +4037,9 @@ gfc_free_namespace (gfc_namespace *ns) return; ns->refs--; - if (ns->refs > 0) -return; - gcc_assert (ns->refs == 0); + if (ns->refs != 0) +return; gfc_free_statements (ns->code); The ChangeLog doesn't seem to match the patch. If ns->refs==0, you free the namespace. If ns->refs!=0, you return. So, if ns->refs<0, the namespace is not freed. That is what I get when I am in hurry. Try this: PR fortran/84506 * symbol.c (gfc_free_namespace): Delete the assert and only if refs count equals zero, free the namespece. Otherwise, something is halfway and other errors will resound.
[PATCH] i386: Insert ENDBR to trampoline for -fcf-protection=branch -mibt
When -fcf-protection=branch -mibt are used, we need to insert ENDBR
to trampoline. TRAMPOLINE_SIZE is creased by 4 bytes to accommodate
4-byte ENDBR instruction.
OK for trunk?
H.J.
gcc/
PR target/85044
* config/i386/i386.c (ix86_trampoline_init): Insert ENDBR for
-fcf-protection=branch -mibt.
* config/i386/i386.h (TRAMPOLINE_SIZE): Increased by 4 bytes.
gcc/testsuite/
PR target/85044
* gcc.target/i386/pr85044.c: New test.
---
gcc/config/i386/i386.c | 17 +
gcc/config/i386/i386.h | 2 +-
gcc/testsuite/gcc.target/i386/pr85044.c | 24
3 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr85044.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3b264318f50..b4f6aec1434 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30411,6 +30411,7 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx
chain_value)
rtx mem, fnaddr;
int opcode;
int offset = 0;
+ bool need_endbr = (flag_cf_protection & CF_BRANCH) && TARGET_IBT;
fnaddr = XEXP (DECL_RTL (fndecl), 0);
@@ -30418,6 +30419,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx
chain_value)
{
int size;
+ if (need_endbr)
+ {
+ /* Insert ENDBR64. */
+ mem = adjust_address (m_tramp, SImode, offset);
+ emit_move_insn (mem, gen_int_mode (0xfa1e0ff3, SImode));
+ offset += 4;
+ }
+
/* Load the function address to r11. Try to load address using
the shorter movl instead of movabs. We may want to support
movq for kernel mode, but kernel does not use trampolines at
@@ -30495,6 +30504,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx
chain_value)
else
opcode = 0x68;
+ if (need_endbr)
+ {
+ /* Insert ENDBR32. */
+ mem = adjust_address (m_tramp, SImode, offset);
+ emit_move_insn (mem, gen_int_mode (0xfb1e0ff3, SImode));
+ offset += 4;
+ }
+
mem = adjust_address (m_tramp, QImode, offset);
emit_move_insn (mem, gen_int_mode (opcode, QImode));
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 7f4b04f421d..c7f9b4551b3 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1716,7 +1716,7 @@ typedef struct ix86_args {
/* Length in units of the trampoline for entering a nested function. */
-#define TRAMPOLINE_SIZE (TARGET_64BIT ? 24 : 10)
+#define TRAMPOLINE_SIZE (TARGET_64BIT ? 28 : 14)
/* Definitions for register eliminations.
diff --git a/gcc/testsuite/gcc.target/i386/pr85044.c
b/gcc/testsuite/gcc.target/i386/pr85044.c
new file mode 100644
index 000..332f582d79b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr85044.c
@@ -0,0 +1,24 @@
+/* { dg-do run { target cet } } */
+/* { dg-options "-O2 -fcf-protection=branch -mibt" } */
+
+void callme (void (*callback) (void));
+
+int
+main (void)
+{
+ int ok = 0;
+ void callback (void) { ok = 1; }
+
+ callme (&callback);
+
+ if (!ok)
+ __builtin_abort ();
+ return 0;
+}
+
+__attribute__((noinline, noclone))
+void
+callme (void (*callback) (void))
+{
+ (*callback) ();
+}
--
2.14.3
[testsuite, committed] Make scan pattern more precise in vrp104.c
[ was: Re: [PATCH][RFC] Make expansion of balanced binary trees of
switches on tree level. ]
On 08/30/2017 01:10 PM, Martin Liška wrote:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
index aa3b00a1204..0a952267b29 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
@@ -1,6 +1,8 @@
/* PR tree-optimization/18046 */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
-/* { dg-final { scan-tree-dump-times "switch" 1 "switchlower" } } */
+/* { dg-options "-O2 -fdump-tree-switchlower" } */
+/* We scan for 2 switches as the dump file reports a transformation,
+ IL really contains just a single. */
+/* { dg-final { scan-tree-dump-times "switch" 2 "switchlower" } } */
void foo (void);
void bar (void);
A difference between the optimized and switchlower dumps, is that the
switchlower dump contains a source file path:
...
;; Function test (test, funcdef_no=0, decl_uid=1964, cgraph_uid=0,
symbol_order=0)
beginning to process the following SWITCH statement
(/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c:14)
: ---
switch (i_3(D)) [33.33%], case 1: [33.33%], case 2:
[33.33%]>
test (int i)
{
[local count: 1073741825]:
switch (i_3(D)) [33.33%], case 1: [33.33%], case
2: [33.33%]>
...
So, when I build and tested gcc in a directory containing the string
switch, the scan check failed for me, because it triggered 3 times
instead of 2:
...
gcc.dg/tree-ssa/vrp104.c: pattern found 3 times
FAIL: gcc.dg/tree-ssa/vrp104.c scan-tree-dump-times switchlower "switch" 2
...
Fixed by making the scan pattern more precise.
[ The generic form of this problem is filed as PR82806 - Stabilize paths
in assembler and dumps ]
Committed.
Thanks,
- Tom
[testsuite] Make scan pattern more precise in vrp104.c
2018-03-24 Tom de Vries
* gcc.dg/tree-ssa/vrp104.c: Make scan-tree-dump-times pattern more
precise.
---
gcc/testsuite/gcc.dg/tree-ssa/vrp104.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
index 0a95226..d4691fc 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
@@ -2,7 +2,7 @@
/* { dg-options "-O2 -fdump-tree-switchlower" } */
/* We scan for 2 switches as the dump file reports a transformation,
IL really contains just a single. */
-/* { dg-final { scan-tree-dump-times "switch" 2 "switchlower" } } */
+/* { dg-final { scan-tree-dump-times "switch \\(i_" 2 "switchlower" } } */
void foo (void);
void bar (void);
