[PING] [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)
Hi, I'd like to ping for this patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html I will add a new BZ entry for the (minor) regression this patch introduces in gcc.dg/strlenopt-49.c and assign it to myself. Thanks Bernd. On 07/29/18 12:56, Bernd Edlinger wrote: > Hi! > > This fixes two wrong code bugs where string_constant > returns over length string constants. Initializers > like that are rejected in C++, but valid in C. > > I have xfailed strlenopt-49.c, which tests this feature. > Personally I don't think that it is worth the effort to > optimize something that is per se invalid in C++. > > The hunk in builtins.c is unrelated, but I would like > to use tree_to_shwi here, to be in line with the > tree_fits_shwi_p check above, and the rest of that > function which uses signed HWI throughout. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > > > Thanks > Bernd.
Re: [PATCH][x86] Match movss and movsd "blend" instructions
On Sat, Aug 11, 2018 at 11:54 AM, Allan Sandfeld Jensen
wrote:
> On Samstag, 11. August 2018 11:18:39 CEST Jakub Jelinek wrote:
>> On Sat, Aug 11, 2018 at 10:59:26AM +0200, Allan Sandfeld Jensen wrote:
>> > +/* A subroutine of ix86_expand_vec_perm_builtin_1. Try to implement D
>> > + using movss or movsd. */
>> > +static bool
>> > +expand_vec_perm_movs (struct expand_vec_perm_d *d)
>> > +{
>> > + machine_mode vmode = d->vmode;
>> > + unsigned i, nelt = d->nelt;
>> > + rtx x;
>> > +
>> > + if (d->one_operand_p)
>> > +return false;
>> > +
>> > + if (TARGET_SSE2 && (vmode == V2DFmode || vmode == V4SFmode))
>> > +;
>> > + else
>> > +return false;
>> > +
>> > + /* Only the first element is changed. */
>>
>> Two spaces after .
>>
>> > + if (d->perm[0] != nelt && d->perm[0] != 0)
>> > +return false;
>> > + for (i = 1; i < nelt; ++i) {
>> > +{
>> > + if (d->perm[i] != i + nelt - d->perm[0])
>> > +return false;
>> > +}
>> > + }
>>
>> Extraneous {}s (both pairs, the outer ones even badly indented).
>>
>> Otherwise LGTM.
>>
> Updated:
>
> Note as an infrequent contributor don't have commit access, so I need someone
> reviewing to also commit.
+ if (TARGET_SSE2 && (vmode == V2DFmode || vmode == V4SFmode))
+;
+ else
+return false;
V4SFmode can be used with TARGET_SSE only.
Uros.
[[Patch, fortran] PR86863 - [OOP][F2008] type-bound module procedure name not recognized
I have cast around for a better way to fix this bug but have not come
up with anything. Although brute force, the patch does the job. The
testcase has been extended to include a MODULE PROCEDURE in a
submodule, which I think must have been the contributor's original
intention.
Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
Paul
2017-08-12 Paul Thomas
PR fortran/86863
* resolve.c (resolve_typebound_call): If the TBP is not marked
as a subroutine, check the specific symbol.
2017-08-12 Paul Thomas
PR fortran/86863
* gfortran.dg/submodule_32.f08: New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 263494)
--- gcc/fortran/resolve.c (working copy)
*** resolve_typebound_call (gfc_code* c, con
*** 6266,6274
/* Check that's really a SUBROUTINE. */
if (!c->expr1->value.compcall.tbp->subroutine)
{
! gfc_error ("%qs at %L should be a SUBROUTINE",
! c->expr1->value.compcall.name, &c->loc);
! return false;
}
if (!check_typebound_baseobject (c->expr1))
--- 6266,6282
/* Check that's really a SUBROUTINE. */
if (!c->expr1->value.compcall.tbp->subroutine)
{
! if (!c->expr1->value.compcall.tbp->is_generic
! && c->expr1->value.compcall.tbp->u.specific
! && c->expr1->value.compcall.tbp->u.specific->n.sym
! && c->expr1->value.compcall.tbp->u.specific->n.sym->attr.subroutine)
! c->expr1->value.compcall.tbp->subroutine = 1;
! else
! {
! gfc_error ("%qs at %L should be a SUBROUTINE",
! c->expr1->value.compcall.name, &c->loc);
! return false;
! }
}
if (!check_typebound_baseobject (c->expr1))
Index: gcc/testsuite/gfortran.dg/submodule_32.f08
===
*** gcc/testsuite/gfortran.dg/submodule_32.f08 (nonexistent)
--- gcc/testsuite/gfortran.dg/submodule_32.f08 (working copy)
***
*** 0
--- 1,62
+ ! { dg-do run }
+ !
+ ! Test the fix for PR86863, where the Type Bound Procedures were
+ ! not flagged as subroutines thereby causing an error at the call
+ ! statements.
+ !
+ ! Contributed by Damian Rouson
+ !
+ module foo
+ implicit none
+ integer :: flag = 0
+ type bar
+ contains
+ procedure, nopass :: foobar
+ procedure, nopass :: barfoo
+ end type
+ contains
+ subroutine foobar
+ flag = 1
+ end subroutine
+ subroutine barfoo
+ flag = 0
+ end subroutine
+ end module
+
+ module foobartoo
+ implicit none
+ interface
+ module subroutine set(object)
+ use foo
+ implicit none
+ type(bar) object
+ end subroutine
+ module subroutine unset(object)
+ use foo
+ implicit none
+ type(bar) object
+ end subroutine
+ end interface
+ contains
+ module procedure unset
+ use foo, only : bar
+ call object%barfoo
+ end procedure
+ end module
+
+ submodule(foobartoo) subfoobar
+ contains
+ module procedure set
+ use foo, only : bar
+ call object%foobar
+ end procedure
+ end submodule
+
+ use foo
+ use foobartoo
+ type(bar) :: obj
+ call set(obj)
+ if (flag .ne. 1) stop 1
+ call unset(obj)
+ if (flag .ne. 0) stop 2
+ end
Re: C++ PATCH to implement C++20 P0806R2, Deprecate implicit capture of this via [=]
On Sun, Aug 12, 2018 at 3:53 PM, Marek Polacek wrote: > - var = add_capture (lambda, > -id, > -initializer, > -/*by_reference_p=*/ > - (this_capture_p > -|| (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda) > -== CPLD_REFERENCE)), > - /*explicit_init_p=*/false); > + var = add_capture (lambda, id, initializer, > +/*by_reference_p=*/ > +(this_capture_p > + || (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda) > + == CPLD_REFERENCE)), > +/*explicit_init_p=*/false); This reformatting seems unnecessary, and I prefer to avoid unnecessary reformatting to avoid noise in 'git blame'. The rest of the patch is OK. Jason
Re: C++ PATCH for c++/86915, ICE with auto[]
OK.
On Sun, Aug 12, 2018 at 4:53 AM, Marek Polacek wrote:
> This fixes ICE-on-invalid with an array of auto. The problem was that
> create_array_type_for_decl got null name, so the error call crashed. We
> need to handle this case as elsewhere in the function.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-08-11 Marek Polacek
>
> PR c++/86915
> * decl.c (create_array_type_for_decl): Handle null name.
>
> * g++.dg/diagnostic/auto1.C: New test.
>
> --- gcc/cp/decl.c
> +++ gcc/cp/decl.c
> @@ -9838,7 +9838,10 @@ create_array_type_for_decl (tree name, tree type, tree
> size)
> type-specifier, the program is ill-formed. */
>if (type_uses_auto (type))
> {
> - error ("%qD declared as array of %qT", name, type);
> + if (name)
> + error ("%qD declared as array of %qT", name, type);
> + else
> + error ("creating array of %qT", type);
>return error_mark_node;
> }
>
> --- gcc/testsuite/g++.dg/diagnostic/auto1.C
> +++ gcc/testsuite/g++.dg/diagnostic/auto1.C
> @@ -0,0 +1,4 @@
> +// PR c++/86915
> +// { dg-do compile { target c++17 } }
> +
> +template struct S; // { dg-error "creating array of .auto." }
