Re: V2: [PATCH] Update preferred_stack_boundary only when expanding function call
"H.J. Lu" writes:
> On Fri, Jun 7, 2019 at 1:22 AM Richard Biener wrote:
>>
>> On Fri, 7 Jun 2019, Richard Sandiford wrote:
>>
>> > "H.J. Lu" writes:
>> > > locate_and_pad_parm is called when expanding function call from
>> > > initialize_argument_information and when generating function body
>> > > from assign_parm_find_entry_rtl:
>> > >
>> > > /* Remember if the outgoing parameter requires extra alignment on the
>> > > calling function side. */
>> > > if (crtl->stack_alignment_needed < boundary)
>> > > crtl->stack_alignment_needed = boundary;
>> > > if (crtl->preferred_stack_boundary < boundary)
>> > > crtl->preferred_stack_boundary = boundary;
>> > >
>> > > stack_alignment_needed and preferred_stack_boundary should be updated
>> > > only when expanding function call, not when generating function body.
>> > > Add an argument, outgoing_p, to locate_and_pad_parm to indicate for
>> > > expanding function call. Update stack_alignment_needed and
>> > > preferred_stack_boundary if the parameter is passed on stack and only
>> > > when expanding function call.
>> > >
>> > > Tested on Linux/x86-64.
>> > >
>> > > OK for trunk?
>> > >
>> > > Thanks.
>> > >
>> > > --
>> > > H.J.
>> > >
>> > > From e91e20ad8e10373db2c6d8f99a3da0bbf46c5c34 Mon Sep 17 00:00:00 2001
>> > > From: "H.J. Lu"
>> > > Date: Wed, 5 Jun 2019 12:55:19 -0700
>> > > Subject: [PATCH] Update preferred_stack_boundary only when expanding
>> > > function
>> > > call
>> > >
>> > > locate_and_pad_parm is called when expanding function call from
>> > > initialize_argument_information and when generating function body
>> > > from assign_parm_find_entry_rtl:
>> > >
>> > > /* Remember if the outgoing parameter requires extra alignment on the
>> > > calling function side. */
>> > > if (crtl->stack_alignment_needed < boundary)
>> > > crtl->stack_alignment_needed = boundary;
>> > > if (crtl->preferred_stack_boundary < boundary)
>> > > crtl->preferred_stack_boundary = boundary;
>> > >
>> > > stack_alignment_needed and preferred_stack_boundary should be updated
>> > > only when expanding function call, not when generating function body.
>> > > Add an argument, outgoing_p, to locate_and_pad_parm to indicate for
>> > > expanding function call. Update stack_alignment_needed and
>> > > preferred_stack_boundary if the parameter is passed on stack and only
>> > > when expanding function call.
>> > >
>> > > Tested on Linux/x86-64.
>> > >
>> > > gcc/
>> > >
>> > > PR rtl-optimization/90765
>> > > * function.c (assign_parm_find_entry_rtl): Pass false to
>> > > locate_and_pad_parm.
>> > > (locate_and_pad_parm): Add an argument, outgoing_p, to indicate
>> > > for expanding function call. Update stack_alignment_needed and
>> > > preferred_stack_boundary only if outgoing_p is true and the
>> > > the parameter is passed on stack.
>> > > * function.h (locate_and_pad_parm): Add an argument, outgoing_p,
>> > > defaulting to true.
>> > >
>> > > gcc/testsuite/
>> > >
>> > > PR rtl-optimization/90765
>> > > * gcc.target/i386/pr90765-1.c: New test.
>> > > * gcc.target/i386/pr90765-2.c: Likewise.
>> > > ---
>> > > gcc/function.c| 21 +
>> > > gcc/function.h| 3 ++-
>> > > gcc/testsuite/gcc.target/i386/pr90765-1.c | 11 +++
>> > > gcc/testsuite/gcc.target/i386/pr90765-2.c | 18 ++
>> > > 4 files changed, 44 insertions(+), 9 deletions(-)
>> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr90765-1.c
>> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr90765-2.c
>> > >
>> > > diff --git a/gcc/function.c b/gcc/function.c
>> > > index e30ee259bec..9b6673f6f0d 100644
>> > > --- a/gcc/function.c
>> > > +++ b/gcc/function.c
>> > > @@ -2601,7 +2601,7 @@ assign_parm_find_entry_rtl (struct
>> > > assign_parm_data_all *all,
>> > >locate_and_pad_parm (data->promoted_mode, data->passed_type, in_regs,
>> > >all->reg_parm_stack_space,
>> > >entry_parm ? data->partial : 0, current_function_decl,
>> > > - &all->stack_args_size, &data->locate);
>> > > + &all->stack_args_size, &data->locate, false);
>> > >
>> > >/* Update parm_stack_boundary if this parameter is passed in the
>> > > stack. */
>> > > @@ -3954,7 +3954,8 @@ locate_and_pad_parm (machine_mode passed_mode,
>> > > tree type, int in_regs,
>> > > int reg_parm_stack_space, int partial,
>> > > tree fndecl ATTRIBUTE_UNUSED,
>> > > struct args_size *initial_offset_ptr,
>> > > -struct locate_and_pad_arg_data *locate)
>> > > +struct locate_and_pad_arg_data *locate,
>> > > +bool outgoing_p)
>> > > {
>> > >tree sizetree;
>> > >pad_direction where_pad;
>> > > @@ -4021,12 +4022,16 @@ locate_and_pad_parm (machine_mode passed_mode,
>> > > tree type, int i
Re: [AArch64] [SVE] PR88837 - Poor vector construction code in VL-specific mode
On Fri, 7 Jun 2019 at 22:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > 2019-06-07 Prathamesh Kulkarni
> >
> > * gcc.target/aarch64/sve/init_1.c: Remove options
> > -O2 -fno-schedule-insns and instead pass -O.
> > Update assembly in comments.
> > * gcc.target/aarch64/sve/init_2.c: Likewise.
> > * gcc.target/aarch64/sve/init_3.c: Likewise.
> > * gcc.target/aarch64/sve/init_4.c: Likewise.
> > * gcc.target/aarch64/sve/init_5.c: Likewise and additionally
> > adjust dg-scan.
> > * gcc.target/aarch64/sve/init_6.c: Likewise.
> > * gcc.target/aarch64/sve/init_7.c: Likewise.
> > * gcc.target/aarch64/sve/init_8.c: Likewise.
> > * gcc.target/aarch64/sve/init_9.c: Likewise.
> > * gcc.target/aarch64/sve/init_10.c: Likewise.
> > * gcc.target/aarch64/sve/init_11.c: Likewise.
> > * gcc.target/aarch64/sve/init_12.c: Likewise.
> >
> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/init_1.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/init_1.c
> > index 5c14b603f46..4f18088f3b0 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/sve/init_1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/init_1.c
> > @@ -1,5 +1,5 @@
> > /* { dg-do assemble { target aarch64_asm_sve_ok } } */
> > -/* { dg-options "-O2 -fno-schedule-insns -msve-vector-bits=256
> > --save-temps" } */
> > +/* { dg-options "-O -msve-vector-bits=256 --save-temps" } */
> >
> > /* Case 1.1: Trailing constants with stepped sequence. */
> >
> > @@ -17,10 +17,10 @@ vnx4si foo(int a, int b)
> > foo:
> > .LFB0:
> > .cfi_startproc
> > -ptrue p0.s, vl8
> > index z0.s, #1, #1
> > insrz0.s, w1
> > insrz0.s, w0
> > +ptrue p0.s, vl8
> > ret
> > */
>
> Let's drop the ptrues as well, since they only exist to feed the
> st1ws and are rightly not part of the matched code. (Same for all
> tests that have a ptrue at the end.)
>
> OK with that change, thanks.
Thanks for the suggestions, I removed dead ptrue's and committed the
patch in r272073.
PS: I am on vacation next week, will start working on PR88833 after that.
Thanks,
Prathamesh
>
> Richard
[C++ PATCH] Add test for c++/72845
This was crashing because our handling of friend decls with noexcept-specifiers
was broken. Fixed by fairly recent r270005.
Tested x86_64-linux, applying to trunk.
2019-06-08 Marek Polacek
PR c++/72845.patch
* g++.dg/cpp0x/noexcept41.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/noexcept41.C
gcc/testsuite/g++.dg/cpp0x/noexcept41.C
new file mode 100644
index 000..4cd3d8d7854
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/noexcept41.C
@@ -0,0 +1,12 @@
+// PR c++/72845
+// { dg-do compile { target c++11 } }
+
+template struct g { static const int h = 0; };
+template void declval() { static_assert(!g::h,""); }
+template struct a {
+ template
+ friend auto f(d &&, c &&) noexcept(declval) -> decltype(declval); // {
dg-error "different exception" }
+};
+template auto f(d &&, c &&) -> decltype(declval);
+struct e {};
+static_assert((e{}, declval>),""); // { dg-error "no context to resolve
type" }
Re: [C++ PATCH] Add test for c++/72845
On Sat, Jun 08, 2019 at 08:48:43AM -0400, Marek Polacek wrote: > This was crashing because our handling of friend decls with > noexcept-specifiers > was broken. Fixed by fairly recent r270005. > > Tested x86_64-linux, applying to trunk. > > 2019-06-08 Marek Polacek > > PR c++/72845.patch Oop. Fixed this before committing the test. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: [C++ PATCH] Add test for c++/72845
On Sat, Jun 08, 2019 at 08:48:43AM -0400, Marek Polacek wrote:
> This was crashing because our handling of friend decls with
> noexcept-specifiers
> was broken. Fixed by fairly recent r270005.
>
> Tested x86_64-linux, applying to trunk.
>
> 2019-06-08 Marek Polacek
>
> PR c++/72845.patch
s/\.patch//
> * g++.dg/cpp0x/noexcept41.C: New test.
>
> diff --git gcc/testsuite/g++.dg/cpp0x/noexcept41.C
> gcc/testsuite/g++.dg/cpp0x/noexcept41.C
> new file mode 100644
> index 000..4cd3d8d7854
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp0x/noexcept41.C
> @@ -0,0 +1,12 @@
> +// PR c++/72845
> +// { dg-do compile { target c++11 } }
> +
> +template struct g { static const int h = 0; };
> +template void declval() { static_assert(!g::h,""); }
> +template struct a {
> + template
> + friend auto f(d &&, c &&) noexcept(declval) -> decltype(declval); //
> { dg-error "different exception" }
> +};
> +template auto f(d &&, c &&) -> decltype(declval);
> +struct e {};
> +static_assert((e{}, declval>),""); // { dg-error "no context to
> resolve type" }
Jakub
[C++ PATCH] Add test for c++/77548
Continuing scouring older C++ PRs. This one ICEd but was fixed by r240098;
let's make sure we don't re-introduce that bug.
Tested x86_64-linux, applying to trunk.
2019-06-08 Marek Polacek
PR c++/77548
* g++.dg/other/pr77548.C: New test.
diff --git gcc/testsuite/g++.dg/other/pr77548.C
gcc/testsuite/g++.dg/other/pr77548.C
new file mode 100644
index 000..842a9e9d28b
--- /dev/null
+++ gcc/testsuite/g++.dg/other/pr77548.C
@@ -0,0 +1,9 @@
+// PR c++/77548
+// { dg-do compile }
+// { dg-options "" }
+
+struct S
+{
+ int f (void) { return 0; }
+ int f (int) { return f ? : 1; } // { dg-error "cannot resolve overloaded
function" }
+};
[PATCH] Use consistent spelling of PCLMUL instruction
* doc/invoke.texi (C Dialect Options): Minor grammatical change.
(x86 Options): Replace all uses of "PCL_MUL" with "PCLMUL"
Committed to trunk.
commit 94f631371312bcc6bf1582b867b98e9e8dee43fe
Author: redi
Date: Sat Jun 8 13:40:25 2019 +
Use consistent spelling of PCLMUL instruction
* doc/invoke.texi (C Dialect Options): Minor grammatical change.
(x86 Options): Replace all uses of "PCL_MUL" with "PCLMUL"
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@272081
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fa7d9ea8100..f18d225e5b5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2238,7 +2238,7 @@ Some cases of unnamed fields in structures and unions are
only
accepted with this option. @xref{Unnamed Fields,,Unnamed struct/union
fields within structs/unions}, for details.
-Note that this option is off for all targets but x86
+Note that this option is off for all targets except for x86
targets using ms-abi.
@item -fplan9-extensions
@@ -27376,34 +27376,34 @@ instruction set extensions.)
@item bdver1
CPUs based on AMD Family 15h cores with x86-64 instruction set support. (This
-supersets FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
+supersets FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)
@item bdver2
AMD Family 15h core based CPUs with x86-64 instruction set support. (This
-supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX,
+supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX,
SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set
extensions.)
@item bdver3
AMD Family 15h core based CPUs with x86-64 instruction set support. (This
supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES,
-PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and
+PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and
64-bit instruction set extensions.
@item bdver4
AMD Family 15h core based CPUs with x86-64 instruction set support. (This
supersets BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP,
-AES, PCL_MUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
+AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
SSE4.2, ABM and 64-bit instruction set extensions.
@item znver1
AMD Family 17h core based CPUs with x86-64 instruction set support. (This
supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX,
-SHA, CLZERO, AES, PCL_MUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
+SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64-bit
instruction set extensions.
@item znver2
AMD Family 17h core based CPUs with x86-64 instruction set support. (This
supersets BMI, BMI2, ,CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
-MWAITX, SHA, CLZERO, AES, PCL_MUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
+MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64-bit
instruction set extensions.)
@@ -27415,7 +27415,7 @@ instruction set extensions.)
@item btver2
CPUs based on AMD Family 16h cores with x86-64 instruction set support. This
-includes MOVBE, F16C, BMI, AVX, PCL_MUL, AES, SSE4.2, SSE4.1, CX16, ABM,
+includes MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM,
SSE4A, SSSE3, SSE3, SSE2, SSE, MMX and 64-bit instruction set extensions.
@item winchip-c6
[patch, committed] PR 90744
Hello world,
I have just committed the attached patch to trunk as obvious an simple.
The problem, which led to wrong code, was that copying the "deferred"
attribute from the dummy to the formal argument a) makes no sense b)
led to wrong code. The analysis and the first working version of the
patch was done by Tomáš Trnka (thanks!).
I will also backport, since this is a 7/8/9/10 regression.
Regards
Thomas
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90744
* trans-types.c (get_formal_from_actual_arglist): Unset typespec
flags which make no sense for procedures without explicit
interface.
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90744
* gfortran.dg/deferred_character_33.f90: New test.
* gfortran.dg/deferred_character_33a.f90: New test.
Index: trans-types.c
===
--- trans-types.c (Revision 271945)
+++ trans-types.c (Arbeitskopie)
@@ -3005,6 +3005,9 @@ get_formal_from_actual_arglist (gfc_symbol *sym, g
else
{
s->ts = a->expr->ts;
+ s->ts.deferred = 0;
+ s->ts.is_iso_c = 0;
+ s->ts.is_c_interop = 0;
s->attr.flavor = FL_VARIABLE;
if (a->expr->rank > 0)
{
! { dg-do compile }
subroutine convrs(quanty,fromto)
implicit none
character(*), intent(in) :: quanty,fromto
if (len(fromto) /= 2) stop 1
if (fromto /= 'OK') stop 2
end subroutine
! { dg-do run }
! { dg-additional-sources deferred_character_33a.f90 }
! PR fortran/90744 - this used to pass a wrong length
! to an external function without a prototype.
! Original test case by Tomáš Trnka.
module StringModule
implicit none
contains
function getstr()
character(:), allocatable :: getstr
getstr = 'OK'
end function
end module
module TestModule
use StringModule
implicit none
contains
subroutine DoTest()
if (.false.) then
call convrs('A',getstr())
else
call convrs('B',getstr())
end if
end subroutine
end module
program external_char_length
use TestModule
implicit none
call DoTest()
end program
[C++ PATCH] Add test for c++/52269
Continuing scouring the Bugzilla. This one compiles fine since r224008
which deferred instantiating constexpr functions until we actually need the
definition.
Tested other compilers too; all of them accept the test.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2019-06-08 Marek Polacek
PR c++/52269
* g++.dg/cpp0x/constexpr-decltype4.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-decltype4.C
gcc/testsuite/g++.dg/cpp0x/constexpr-decltype4.C
new file mode 100644
index 000..64af90baee4
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-decltype4.C
@@ -0,0 +1,21 @@
+// PR c++/52269
+// { dg-do compile { target c++11 } }
+
+template
+int f(T x)
+{
+ return x.get();
+}
+
+// O.K. The body of `f' is not required.
+decltype(f(0)) a;
+
+template
+constexpr int g(T x)
+{
+ return x.get();
+}
+
+// Seems to instantiate the body of `g'
+// and results in an error.
+decltype(g(0)) b;
[Patch, fortran] PR90786 - [7/8/9/10 Regression] ICE on procedure pointer assignment to function with class pointer result
Committed as obvious in revision 272084.
The problem was that the lhs symbol itself was not being checked as a
proc_pointer - just the expression component.
I will get on with backporting tomorrow.
Cheers
Paul
2019-06-08 Paul Thomas
PR fortran/90786
* trans-expr.c (pointer_assignment_is_proc_pointer) Remove as
it is very simple and only called from one place.
(gfc_trans_pointer_assignment): Rename non_proc_pointer_assign
as non_proc_ptr_assign. Assign to it directly, rather than call
to above, deleted function and use gfc_expr_attr instead of
only checking the reference chain.
2019-06-08 Paul Thomas
PR fortran/90786
* gfortran.dg/proc_ptr_51.f90 : New test.
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c (revision 272076)
--- gcc/fortran/trans-expr.c (working copy)
*** class_array_fcn:
*** 4881,4887
parmse->expr = gfc_build_addr_expr (NULL_TREE, parmse->expr);
/* Basically make this into
!
if (present)
{
if (contiguous)
--- 4881,4887
parmse->expr = gfc_build_addr_expr (NULL_TREE, parmse->expr);
/* Basically make this into
!
if (present)
{
if (contiguous)
*** trans_caf_token_assign (gfc_se *lse, gfc
*** 8979,9001
}
}
- /* Indentify class valued proc_pointer assignments. */
-
- static bool
- pointer_assignment_is_proc_pointer (gfc_expr * expr1, gfc_expr * expr2)
- {
- gfc_ref * ref;
-
- ref = expr1->ref;
- while (ref && ref->next)
- ref = ref->next;
-
- return ref && ref->type == REF_COMPONENT
- && ref->u.c.component->attr.proc_pointer
- && expr2->expr_type == EXPR_VARIABLE
- && expr2->symtree->n.sym->attr.flavor == FL_PROCEDURE;
- }
-
/* Do everything that is needed for a CLASS function expr2. */
--- 8979,8984
*** gfc_trans_pointer_assignment (gfc_expr *
*** 9048,9054
tree desc;
tree tmp;
tree expr1_vptr = NULL_TREE;
! bool scalar, non_proc_pointer_assign;
gfc_ss *ss;
gfc_start_block (&block);
--- 9031,9037
tree desc;
tree tmp;
tree expr1_vptr = NULL_TREE;
! bool scalar, non_proc_ptr_assign;
gfc_ss *ss;
gfc_start_block (&block);
*** gfc_trans_pointer_assignment (gfc_expr *
*** 9056,9062
gfc_init_se (&lse, NULL);
/* Usually testing whether this is not a proc pointer assignment. */
! non_proc_pointer_assign = !pointer_assignment_is_proc_pointer (expr1, expr2);
/* Check whether the expression is a scalar or not; we cannot use
expr1->rank as it can be nonzero for proc pointers. */
--- 9039,9047
gfc_init_se (&lse, NULL);
/* Usually testing whether this is not a proc pointer assignment. */
! non_proc_ptr_assign = !(gfc_expr_attr (expr1).proc_pointer
! && expr2->expr_type == EXPR_VARIABLE
! && expr2->symtree->n.sym->attr.flavor == FL_PROCEDURE);
/* Check whether the expression is a scalar or not; we cannot use
expr1->rank as it can be nonzero for proc pointers. */
*** gfc_trans_pointer_assignment (gfc_expr *
*** 9066,9072
gfc_free_ss_chain (ss);
if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
! && expr2->expr_type != EXPR_FUNCTION && non_proc_pointer_assign)
{
gfc_add_data_component (expr2);
/* The following is required as gfc_add_data_component doesn't
--- 9051,9057
gfc_free_ss_chain (ss);
if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
! && expr2->expr_type != EXPR_FUNCTION && non_proc_ptr_assign)
{
gfc_add_data_component (expr2);
/* The following is required as gfc_add_data_component doesn't
*** gfc_trans_pointer_assignment (gfc_expr *
*** 9086,9092
else
gfc_conv_expr (&rse, expr2);
! if (non_proc_pointer_assign && expr1->ts.type == BT_CLASS)
{
trans_class_vptr_len_assignment (&block, expr1, expr2, &rse, NULL,
NULL);
--- 9071,9077
else
gfc_conv_expr (&rse, expr2);
! if (non_proc_ptr_assign && expr1->ts.type == BT_CLASS)
{
trans_class_vptr_len_assignment (&block, expr1, expr2, &rse, NULL,
NULL);
Index: gcc/testsuite/gfortran.dg/proc_ptr_51.f90
===
*** gcc/testsuite/gfortran.dg/proc_ptr_51.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/proc_ptr_51.f90 (working copy)
***
*** 0
--- 1,38
+ ! { dg-do run }
+ !
+ ! Test the fix for PR90786.
+ !
+ ! Contributed by Andrew benson
+ !
+ module f
+ procedure(c), pointer :: c_
+
+ type :: s
+integer :: i = 42
+ end type s
+ class(s), pointer :: res, tgt
+
+ contains
+
+ function c()
+implicit none
+class(s), pointer :: c
+c => tgt
+return
+ end function c
+
+ subroutine fs()
+implicit none
+c_ => c ! This used
Re: Test for C++20 p0858 - ConstexprIterator requirements.
On 6/7/19 11:42 AM, Jonathan Wakely wrote:
On 01/06/19 15:40 -0400, Ed Smith-Rowland via libstdc++ wrote:
On 6/1/19 2:42 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 21:09, Ed Smith-Rowland <3dw...@verizon.net>
wrote:
On 5/31/19 6:29 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
Greetings,
Iterators for and are usabe in a constexpr
context
since C++2017.
This just adds a compile test to make sure and check a box for C++20
p0858 - ConstexprIterator requirements.
Those tests don't use the iterators in a constexpr context. To do
that, maybe do those std::copy operations
in a constexpr function and then initialize a constexpr variable with
the result of a call to that function?
Thanks Ville,
I had completely forgotten to make these test functions constexpr -
FIXED.
.but that doesn't enforce a constexpr context. If you add another
function that calls these functions
and initializes a constexpr variable, then we have the enforcement I
seek. Such as
void test2()
{
?? constexpr char x = test();
}
Ok, third time's a charm.
I was brain dead about the constexpr patch.?? I'm now setting a
constexpr variable from test() in a caller.
But static_assert is a constexpr context no?
Ed
2019-06-03?? Edward Smith-Rowland <3dw...@verizon.net>
Test for C++20 p0858 - ConstexprIterator requirements.
*
testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc:
New test.
* testsuite/23_containers/array/requirements/constexpr_iter.cc:
New test.
Index:
testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
===
---
testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(nonexistent)
+++
testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(working copy)
@@ -0,0 +1,43 @@
+// { dg-do compile { target c++2a } }
Please check the testsuite/libstdc++.log or testsuite/libstdc++.sum
files for the new tests. I expect they are both UNSUPPORTED.
That's because you've given a target c++2a which means they won't be
run unless a suitable -std option is given. And you haven't given one.
You need to add { dg-options "-std=gnu++2a" } before the dg-do line.
Also if the tests are restricted to C++2a then there's no point having
the #if __cplusplus > 201703L check, because that will never be false.
I had supplied the option for gnu++2a by hand and they passed.?? They
were not UNSUPPORTED.
I just added the dg-options (at very top) and reran the testsuite
without fancy tricks (except for gnu++2a).
I also took out the #if __cplusplus.?? I was just playing around and
discovered that these pass in C++17 if you comment out the C++20
constexpr algos.
OK for trunk?
Also, we could declare victory for this for gcc-9.?? May I backport after
this is in?
Ed
2019-06-10 Edward Smith-Rowland <3dw...@verizon.net>
Test for C++20 p0858 - ConstexprIterator requirements.
* testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc:
New test.
* testsuite/23_containers/array/requirements/constexpr_iter.cc:
New test.
Index: testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
===
--- testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(nonexistent)
+++ testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(working copy)
@@ -0,0 +1,42 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+//
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [Patch, fortran] PR90786 - [7/8/9/10 Regression] ICE on procedure pointer assignment to function with class pointer result
Thanks Paul for the quick fix! On Saturday, June 8, 2019 4:56:46 PM PDT Paul Richard Thomas wrote: > Committed as obvious in revision 272084. > > The problem was that the lhs symbol itself was not being checked as a > proc_pointer - just the expression component. > > I will get on with backporting tomorrow. > > Cheers > > Paul > > 2019-06-08 Paul Thomas > > PR fortran/90786 > * trans-expr.c (pointer_assignment_is_proc_pointer) Remove as > it is very simple and only called from one place. > (gfc_trans_pointer_assignment): Rename non_proc_pointer_assign > as non_proc_ptr_assign. Assign to it directly, rather than call > to above, deleted function and use gfc_expr_attr instead of > only checking the reference chain. > > 2019-06-08 Paul Thomas > > PR fortran/90786 > * gfortran.dg/proc_ptr_51.f90 : New test. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/galacticusdev/galacticus
Re: Test for C++20 p0858 - ConstexprIterator requirements.
On 08/06/19 12:05 -0400, Ed Smith-Rowland wrote:
On 6/7/19 11:42 AM, Jonathan Wakely wrote:
On 01/06/19 15:40 -0400, Ed Smith-Rowland via libstdc++ wrote:
On 6/1/19 2:42 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 21:09, Ed Smith-Rowland
<3dw...@verizon.net> wrote:
On 5/31/19 6:29 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
Greetings,
Iterators for and are usabe in a
constexpr context
since C++2017.
This just adds a compile test to make sure and check a box for C++20
p0858 - ConstexprIterator requirements.
Those tests don't use the iterators in a constexpr context. To do
that, maybe do those std::copy operations
in a constexpr function and then initialize a constexpr variable with
the result of a call to that function?
Thanks Ville,
I had completely forgotten to make these test functions
constexpr - FIXED.
.but that doesn't enforce a constexpr context. If you add another
function that calls these functions
and initializes a constexpr variable, then we have the enforcement I
seek. Such as
void test2()
{
?? constexpr char x = test();
}
Ok, third time's a charm.
I was brain dead about the constexpr patch.?? I'm now setting a
constexpr variable from test() in a caller.
But static_assert is a constexpr context no?
Ed
2019-06-03?? Edward Smith-Rowland <3dw...@verizon.net>
Test for C++20 p0858 - ConstexprIterator requirements.
* testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc:
New test.
* testsuite/23_containers/array/requirements/constexpr_iter.cc:
New test.
Index: testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
===
--- testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(nonexistent)
+++ testsuite/21_strings/basic_string_view/requirements/constexpr_iter.cc
(working copy)
@@ -0,0 +1,43 @@
+// { dg-do compile { target c++2a } }
Please check the testsuite/libstdc++.log or testsuite/libstdc++.sum
files for the new tests. I expect they are both UNSUPPORTED.
That's because you've given a target c++2a which means they won't be
run unless a suitable -std option is given. And you haven't given one.
You need to add { dg-options "-std=gnu++2a" } before the dg-do line.
Also if the tests are restricted to C++2a then there's no point having
the #if __cplusplus > 201703L check, because that will never be false.
I had supplied the option for gnu++2a by hand and they passed.?? They
were not UNSUPPORTED.
I just added the dg-options (at very top) and reran the testsuite
without fancy tricks (except for gnu++2a).
I also took out the #if __cplusplus.?? I was just playing around and
discovered that these pass in C++17 if you comment out the C++20
constexpr algos.
OK for trunk?
OK for trunk.
Also, we could declare victory for this for gcc-9.?? May I backport
after this is in?
Yes, these tests are also OK to backport to gcc-9-branch (assuming
they pass on the branch, which I agree they should do).
Thanks!
fold_real_zero_addition_p for vectors
Hello,
this small tweak of fold_real_zero_addition_p lets it handle vectors as
well.
Bootstrap and regtest on x86_64-pc-linux-gnu.
2019-06-10 Marc Glisse
PR tree-optimization/62041
* fold-const.c (fold_real_zero_addition_p): Handle vectors.
--
Marc GlisseIndex: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 272076)
+++ gcc/fold-const.c (working copy)
@@ -6715,40 +6715,45 @@ fold_binary_op_with_conditional_arg (loc
X - 0 is not the same as X because 0 - 0 is -0. In other rounding
modes, X + 0 is not the same as X because -0 + 0 is 0. */
bool
fold_real_zero_addition_p (const_tree type, const_tree addend, int negate)
{
if (!real_zerop (addend))
return false;
/* Don't allow the fold with -fsignaling-nans. */
- if (HONOR_SNANS (element_mode (type)))
+ if (HONOR_SNANS (type))
return false;
/* Allow the fold if zeros aren't signed, or their sign isn't important. */
- if (!HONOR_SIGNED_ZEROS (element_mode (type)))
+ if (!HONOR_SIGNED_ZEROS (type))
return true;
+ /* There is no case that is safe for all rounding modes. */
+ if (HONOR_SIGN_DEPENDENT_ROUNDING (type))
+return false;
+
/* In a vector or complex, we would need to check the sign of all zeros. */
- if (TREE_CODE (addend) != REAL_CST)
+ if (TREE_CODE (addend) == VECTOR_CST)
+addend = uniform_vector_p (addend);
+ if (!addend || TREE_CODE (addend) != REAL_CST)
return false;
/* Treat x + -0 as x - 0 and x - -0 as x + 0. */
if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (addend)))
negate = !negate;
/* The mode has signed zeros, and we have to honor their sign.
In this situation, there is only one case we can return true for.
- X - 0 is the same as X unless rounding towards -infinity is
- supported. */
- return negate && !HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type));
+ X - 0 is the same as X with default rounding. */
+ return negate;
}
/* Subroutine of match.pd that optimizes comparisons of a division by
a nonzero integer constant against an integer constant, i.e.
X/C1 op C2.
CODE is the comparison operator: EQ_EXPR, NE_EXPR, GT_EXPR, LT_EXPR,
GE_EXPR or LE_EXPR. ARG01 and ARG1 must be a INTEGER_CST. */
enum tree_code
[PATCH v2] [MIPS] Inhibit trailing .insn if pool is not followed by code
The __pool and __pend symbols are used to mark the beginning and end
of inline constant pools in MIPS16 code regions. However if the pool
occurs at the boundary of a code region and is not followed by further
code, presence of the __pend symbol can confuse the dissassembler in
to treating subsequent non-MIPS16 code block as MIPS16. Change the
type of the __pend symbol depending on whether it is followed by
further code to inhibit the trailing .insn.
Based on original patch from Maciej W. Rozycki
gcc/
* config/mips/mips.c (mips_final_postscan_insn): Modify call
to `mips_set_text_contents_type' to indicate whether a
non-debug insn follows.
gcc/gcc/testsuite/
* gcc.target/mips/data-sym-pool.c: Update expected output.
* gcc.target/mips/data-sym-multi-pool.c: New test.
---
gcc/config/mips/mips.c | 16 ++--
.../gcc.target/mips/data-sym-multi-pool.c | 45 ++
gcc/testsuite/gcc.target/mips/data-sym-pool.c | 5 +--
3 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/mips/data-sym-multi-pool.c
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index c6433dc..0e1a68a 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -20636,9 +20636,19 @@ mips_final_postscan_insn (FILE *file ATTRIBUTE_UNUSED,
rtx_insn *insn,
if (INSN_P (insn)
&& GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE
&& XINT (PATTERN (insn), 1) == UNSPEC_CONSTTABLE_END)
-mips_set_text_contents_type (asm_out_file, "__pend_",
-INTVAL (XVECEXP (PATTERN (insn), 0, 0)),
-TRUE);
+{
+ rtx_insn *next_insn = next_real_nondebug_insn (insn);
+ bool code_p = (next_insn != NULL
+&& INSN_P (next_insn)
+&& (GET_CODE (PATTERN (next_insn)) != UNSPEC_VOLATILE
+|| XINT (PATTERN (next_insn), 1) !=
UNSPEC_CONSTTABLE));
+
+ /* Switch content type depending on whether there is code beyond
+the constant pool. */
+ mips_set_text_contents_type (asm_out_file, "__pend_",
+ INTVAL (XVECEXP (PATTERN (insn), 0, 0)),
+ code_p);
+}
}
/* Return the function that is used to expand the mulsidi3 pattern.
diff --git a/gcc/testsuite/gcc.target/mips/data-sym-multi-pool.c
b/gcc/testsuite/gcc.target/mips/data-sym-multi-pool.c
new file mode 100644
index 000..1936f5b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/data-sym-multi-pool.c
@@ -0,0 +1,45 @@
+/* { dg-do compile } */
+/* { dg-options "-mips16 -mcode-readable=yes" } */
+/* { dg-skip-if "per-function expected output" { *-*-* } { "-flto" } { "" } }
*/
+
+/* This testcase generates multiple constant pools within a function body. */
+
+#define C(a,b) \
+ if (a > b) goto gt; \
+ if (a < b) goto lt;
+
+#define C4(x,b) C((x)[0], b) C((x)[1],b) C((x)[2],b) C((x)[3],b)
+#define C16(x,y) C4(x, (y)[0]) C4(x, (y)[1]) C4(x, (y)[2]) C4(x, (y)[3])
+
+#define C64(x,y) C16(x,y) C16(x+4,y) C16(x+8,y)
+#define C256(x,y) C64(x,y) C64(x,y+4) C64(x,y+8)
+
+unsigned foo(int x[64], int y[64])
+{
+ C256(x,y);
+
+ return 0x01234567;
+ gt:
+ return 0x12345678;
+ lt:
+ return 0xF0123456;
+}
+
+/* Check that:
+1. The __pend symbol is emitted as STT_FUNCTION followed by instructions:
+ .type __pend_frob_, @function # Symbol # must match label.
+__pend_foo_:# The symbol must match.
+ .insn
+.L:
+
+2. __pend symbol at end of function has type STT_OBJECT
+
+ .type __pend_foo_, @object
+__pend_foo_:
+ .insn
+ .endfoo
+
+ */
+
+/* { dg-final { scan-assembler "\t\\.type\t(__pend_foo_\[0-9\]+),
@function\n\\1:\n\t\\.insn\n.L\[0-9\]+:\n" } } */
+/* { dg-final { scan-assembler "\t\\.type\t(__pend_foo_\[0-9\]+),
@object\n\\1:\n\t\\.end\tfoo\n" } } */
diff --git a/gcc/testsuite/gcc.target/mips/data-sym-pool.c
b/gcc/testsuite/gcc.target/mips/data-sym-pool.c
index 8776d2b..f093511 100644
--- a/gcc/testsuite/gcc.target/mips/data-sym-pool.c
+++ b/gcc/testsuite/gcc.target/mips/data-sym-pool.c
@@ -16,9 +16,8 @@ __pool_frob_3:# The
symbol must match.
.align 2
$L3: # The label must match.
.word 305419896
- .type __pend_frob_3, @function# Symbol # must match label.
+ .type __pend_frob_3, @object # Symbol # must match label.
__pend_frob_3: # The symbol must match.
- .insn
that is `__pool_*'/`__pend_*' symbols inserted around a constant pool.
@@ -26,4 +25,4 @@ __pend_frob_3:# The
symbol must match.
symbol from being placed in the constant pool at `-O0' for SVR4 code
and consequently interfering with test expectations. */
-/* { dg-final
C++ PATCH for c++/66999 - 'this' captured by reference
This patch improves a diagnostic when parsing a lambda introducer; in
particular,
we should handle '&this' better than we currently do. clang/icc specifically
point out that 'this' cannot be captured by reference, let's do the same.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-08 Marek Polacek
PR c++/66999 - 'this' captured by reference.
* parser.c (cp_parser_lambda_introducer): Reject `&this'. Use
cp_lexer_nth_token_is instead of cp_lexer_peek_nth_token.
* g++.dg/cpp0x/lambda/lambda-this21.C: New test.
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 308b2d4ad70..74796e197fe 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -10526,7 +10526,8 @@ cp_parser_lambda_introducer (cp_parser* parser, tree
lambda_expr)
/* Record default capture mode. "[&" "[=" "[&," "[=," */
if (cp_lexer_next_token_is (parser->lexer, CPP_AND)
- && cp_lexer_peek_nth_token (parser->lexer, 2)->type != CPP_NAME)
+ && !cp_lexer_nth_token_is (parser->lexer, 2, CPP_NAME)
+ && !cp_lexer_nth_token_is_keyword (parser->lexer, 2, RID_THIS))
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) = CPLD_REFERENCE;
else if (cp_lexer_next_token_is (parser->lexer, CPP_EQ))
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) = CPLD_COPY;
@@ -10609,6 +10610,17 @@ cp_parser_lambda_introducer (cp_parser* parser, tree
lambda_expr)
continue;
}
+ /* But reject `&this'. */
+ if (cp_lexer_next_token_is (parser->lexer, CPP_AND)
+ && cp_lexer_nth_token_is_keyword (parser->lexer, 2, RID_THIS))
+ {
+ error_at (cp_lexer_peek_token (parser->lexer)->location,
+ "% cannot be captured by reference");
+ cp_lexer_consume_token (parser->lexer);
+ cp_lexer_consume_token (parser->lexer);
+ continue;
+ }
+
bool init_pack_expansion = false;
location_t ellipsis_loc = UNKNOWN_LOCATION;
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this21.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this21.C
new file mode 100644
index 000..a3256b5700f
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this21.C
@@ -0,0 +1,10 @@
+// PR c++/66999 - 'this' captured by reference.
+// { dg-do compile { target c++11 } }
+
+struct X {
+ void bar (int n)
+{
+ auto l1 = [&this] { }; // { dg-error ".this. cannot be captured by
reference" }
+ auto l2 = [=, &this] { }; // { dg-error ".this. cannot be captured by
reference" }
+}
+};
