When pretty printing a function pointer type via
pp_cxx_parameter_declaration_clause, we end up always printing an empty
parameter list because the loop that's supposed to print the parameter
list iterates over 'args' instead of 'types', and 'args' is empty in
this case when a FUNCTION_TYPE is
On 16/04/21 20:48 +0200, Jakub Jelinek wrote:
On Fri, Apr 16, 2021 at 05:14:58PM +0200, Jakub Jelinek via Gcc-patches wrote:
As we have only one P1 left right now, I think it is the right time
to update abi list files in libstdc++.
Attached are two patches, one is update for
On Fri, Apr 16, 2021 at 05:14:58PM +0200, Jakub Jelinek via Gcc-patches wrote:
> As we have only one P1 left right now, I think it is the right time
> to update abi list files in libstdc++.
>
> Attached are two patches, one is update for x86_64/i?86/s390x/ppc64
> linux (aarch64 seems to be
Hi All!
Proposed patch to:
PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
PR100027 - ICE on storage_size with polymorphic argument
Patch tested only on x86_64-pc-linux-gnu.
Add branch to if clause to handle polymorphic objects, not sure if I got
all possible
Christophe Lyon writes:
> On Thu, 15 Apr 2021 at 17:19, Richard Sandiford via Gcc-patches
> wrote:
>>
>> A lot of the SVE assembly tests are for generic-tuned SVE codegen
>> and so can fail when run on a toolchain configured with --with-cpu.
>>
>> This could easily be solved by forcing
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok, thanks!
Andreas
> ---
>
Jakub Jelinek via Gcc-patches writes:
> On Wed, Apr 07, 2021 at 03:53:26PM +0200, Jakub Jelinek via Gcc-patches wrote:
>> On Mon, Mar 29, 2021 at 11:16:55AM +0200, Jakub Jelinek wrote:
>> > > Looks good to me. Richard E knows this code better than I do though,
>> > > so I think he should have
Sorry the slow reply. I'm not well versed on the all AArch32 combinations
but it looks good to me.
Christophe Lyon via Gcc-patches writes:
> The previous change to this testcase missed the fact that the data may
> be accessed via an anchor, depending on the optimization level,
> leading to
> On Apr 16, 2021, at 6:13 AM, Ville Voutilainen via Gcc-patches
> wrote:
>
> The actual suggestion is at the end; skip straight to it if you wish.
Could you shift this discussion to the gcc list where it fits better?
gcc-patches is for discussion patches to the code.
paul
Hi!
On 2021-04-16T17:05:24+0100, Andrew Stubbs wrote:
> On 15/04/2021 18:26, Thomas Schwinge wrote:
>>> and optimisation, since shared memory might be faster than
>>> the main memory on a GPU.
>>
>> Do we potentially have a problem that making more use of (scarce)
>> gang-private memory may
On 4/15/2021 11:44 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
On s390* the only missing part for the mentioned testcases was a load of
a double floating-point zero via a move (in particular for quite old
machines) which was added in commit 46c47420a5fefd4d9d02b0db347235dd74e20fb2.
On 4/16/2021 9:53 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, building gcc with jit enabled and
--enable-host-shared doesn't work on NetBSD/i?86, as libgccjit.so.0
has text relocations.
The r0-125846-g459260ecf8b420b029601a664cdb21c185268ecb changes
added --enable-host-shared support
Hi All!
Proposed patch to:
PR100120 - associated intrinsic failure
Patch tested only on x86_64-pc-linux-gnu.
Add code to ensure that pointers have the correct dynamic type.
The patch depends on PR100097 and PR100098.
Thank you very much.
Best regards,
José Rui
Fortran: Fix associated
On 15/04/2021 18:26, Thomas Schwinge wrote:
and optimisation, since shared memory might be faster than
the main memory on a GPU.
Do we potentially have a problem that making more use of (scarce)
gang-private memory may negatively affect peformance, because potentially
fewer OpenACC gangs may
Hi!
As mentioned in the PR, building gcc with jit enabled and
--enable-host-shared doesn't work on NetBSD/i?86, as libgccjit.so.0
has text relocations.
The r0-125846-g459260ecf8b420b029601a664cdb21c185268ecb changes
added --enable-host-shared support to various libraries, but didn't
add it to
Hi!
In r11-6895 handling of empty bases has been fixed such that non-lval
stores of empty classes are not added when the type of *valp doesn't
match the type of the initializer, but as this testcase shows it is
done only when *valp is non-NULL. If it is NULL, we still shouldn't
add empty class
On 4/16/21 8:56 AM, Bill Schmidt via Gcc-patches wrote:
> The standard for many Power vector interfaces is now the recently
> published Power Vector Intrinsics Programming Reference. Reference
> that document for the relevant interfaces, and remove redundant
> information from the GCC user's
Tamar Christina writes:
> Hi Richard,
>
> The 04/16/2021 12:23, Richard Sandiford wrote:
>> Tamar Christina writes:
>> > diff --git a/gcc/config/aarch64/aarch64-sve.md
>> > b/gcc/config/aarch64/aarch64-sve.md
>> > index
>> >
Hi Paul, all,
having really enjoyed the review process, I've now committed Paul's version
including his comment. See also attached.
Thanks,
Harald
Gesendet: Freitag, 16. April 2021 um 13:02 Uhr
Von: "Paul Richard Thomas"
An: "Bernhard Reutner-Fischer"
Cc: "Harald Anlauf via Fortran" ,
On 4/16/21 8:56 AM, Bill Schmidt via Gcc-patches wrote:
The standard for many Power vector interfaces is now the recently
published Power Vector Intrinsics Programming Reference. Reference
that document for the relevant interfaces, and remove redundant
information from the GCC user's manual.
Hi Richard,
The 04/16/2021 12:23, Richard Sandiford wrote:
> Tamar Christina writes:
> > diff --git a/gcc/config/aarch64/aarch64-sve.md
> > b/gcc/config/aarch64/aarch64-sve.md
> > index
> > 7db2938bb84e04d066a7b07574e5cf344a3a8fb6..2cdc6338902216760622a39b14f0076994458c98
> > 100644
> > ---
Hi,
checking for an osc break is somewhat brittle especially with many
passes potentially introducing new insns and moving them around.
Therefore, only run the test with -O1 -fschedule-insns in order to limit
the influence of other passes.
Is it OK?
Regards
Robin
--
gcc/testsuite/ChangeLog:
The standard for many Power vector interfaces is now the recently
published Power Vector Intrinsics Programming Reference. Reference
that document for the relevant interfaces, and remove redundant
information from the GCC user's manual.
2021-04-16 Bill Schmidt
gcc/
* doc/extend.texi
On Fri, Apr 16, 2021 at 2:03 PM Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> For z10 and newer inner loops are completely unrolled which means store
> motion is not applied. Reverting max-completely-peeled-insns to the
> default value fixes these testcases.
>
> Ok for mainline?
OK
>
Richard Biener via Gcc-patches writes:
> On Fri, Apr 16, 2021 at 12:02 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> This patch fixes a regression introduced by the rtl-ssa patches.
>> It was seen on HPPA but it might be latent elsewhere.
>>
>> The problem is that the traditional way of
Jakub Jelinek writes:
> On Thu, Apr 15, 2021 at 08:51:03PM +0200, Jakub Jelinek via Gcc-patches wrote:
>> Fixed, thanks for catching that (and the "r" -> "=r"; I've
>> actually tested a patch that didn't have any constraints on the first
>> define_insn because I started with a define_split that
Tamar Christina writes:
> diff --git a/gcc/config/aarch64/aarch64-sve.md
> b/gcc/config/aarch64/aarch64-sve.md
> index
> 7db2938bb84e04d066a7b07574e5cf344a3a8fb6..2cdc6338902216760622a39b14f0076994458c98
> 100644
> --- a/gcc/config/aarch64/aarch64-sve.md
> +++
This simplifies the maybe_fold_reference API reflecting that it
no longer canonicalizes refs (that's done with another function)
but only performs constant folding and thus does nothing for is_lhs.
This in turn allows to rip out quite some dead code and one user
of valid_gimple_rhs_p.
Commit r11-8168 changed the word ordering of a warning in order to
make the text more consistent. Unfortunately, it neglected to update
some filters in the testsuite that are intended to strip such warnings
when we try to partially override the user-supplied command-line
options.
This patch
For z10 and newer inner loops are completely unrolled which means store
motion is not applied. Reverting max-completely-peeled-insns to the
default value fixes these testcases.
Ok for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr83403-1.c: Revert
On Fri, Apr 16, 2021 at 12:02 PM Richard Sandiford via Gcc-patches
wrote:
>
> This patch fixes a regression introduced by the rtl-ssa patches.
> It was seen on HPPA but it might be latent elsewhere.
>
> The problem is that the traditional way of expanding an untyped_call
> is to emit sequences
On Fri, Apr 16, 2021 at 12:01 PM Richard Sandiford via Gcc-patches
wrote:
>
> This patch is a GCC 11 regression caused by the rtl-ssa code.
> Normally we treat calls as containing a potential set of a global
> register, but DF makes a sensible exception for the stack pointer:
>
> if (i ==
On Fri, 16 Apr 2021 at 13:13, Ville Voutilainen
wrote:
>
> The actual suggestion is at the end; skip straight to it if you wish.
..please disregard, that was a send-o, should've have been sent to the
patches mailing list.
The actual suggestion is at the end; skip straight to it if you wish.
>Im glad there are people like you on the project Eric, because you express
exactly what a lot of people see - even if a minority of people chose to
ignore it,
>To a lot of "non americans", the events on here appear as nothing
On Fri, Apr 16, 2021 at 10:17:10AM +0100, Richard Sandiford via Gcc-patches
wrote:
> gcc/
> PR rtl-optimization/99596
> * rtlanal.c (rtx_properties::try_to_add_insn): Don't add global
> register accesses for const calls. Assume that pure functions
> can only read from
On Thu, 15 Apr 2021 at 17:19, Richard Sandiford via Gcc-patches
wrote:
>
> A lot of the SVE assembly tests are for generic-tuned SVE codegen
> and so can fail when run on a toolchain configured with --with-cpu.
>
> This could easily be solved by forcing -mtune=generic, like we already
> do for
Hi All,
The attached testcase generates the following paradoxical subregs when creating
the predicates.
(insn 22 21 23 2 (set (reg:VNx8BI 100)
(subreg:VNx8BI (reg:VNx2BI 103) 0))
(expr_list:REG_EQUAL (const_vector:VNx8BI [
(const_int 1 [0x1])
This moves the legacy gimplify_buildN API to tree-vect-generic.c,
its only user and elides the gimplification step, making it a wrapper
around gimple_build, adjusting tree_vec_extract for this.
I've noticed that vector CTOR expansion doesn't deal with unfolded
{} and thus this makes it more
On Fri, Apr 16, 2021 at 9:02 AM Robin Dapp wrote:
>
> > Do the testcases currently fail? How? In principle moving to vect/
> > is OK but then having the gimplefe testcases in one place is nice ...
>
> yes, they ICE on targets that do not have vector capabilities:
>
> gimplefe-40.c:7:1: internal
This patch fixes a regression introduced by the rtl-ssa patches.
It was seen on HPPA but it might be latent elsewhere.
The problem is that the traditional way of expanding an untyped_call
is to emit sequences like:
(call (mem (symbol_ref "foo")))
(set (reg pseudo1) (reg result1))
...
This patch is a GCC 11 regression caused by the rtl-ssa code.
Normally we treat calls as containing a potential set of a global
register, but DF makes a sensible exception for the stack pointer:
if (i == STACK_POINTER_REGNUM)
/* The stack ptr is used (honorarily) by a CALL insn. */
On Fri, 16 Apr 2021, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because disabling of DCE means there are dead
> stmts in the loop (though, in theory they could become dead only shortly
> before if-conv through some optimization), ifcvt which goes through all
> stmts in the loop
Hi!
The following testcase ICEs because disabling of DCE means there are dead
stmts in the loop (though, in theory they could become dead only shortly
before if-conv through some optimization), ifcvt which goes through all
stmts in the loop if-converts them into .COND_DIV etc. internal fn calls
On Thu, Apr 15, 2021 at 08:51:03PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Fixed, thanks for catching that (and the "r" -> "=r"; I've
> actually tested a patch that didn't have any constraints on the first
> define_insn because I started with a define_split that didn't work,
> and it
fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.
fmodf:
fdivs f0,f1,f2
frizf0,f0
fnmsubs f1,f2,f0,f1
remainderf:
fdivs f0,f1,f2
frinf0,f0
fnmsubs f1,f2,f0,f1
gcc/ChangeLog:
Do the testcases currently fail? How? In principle moving to vect/
is OK but then having the gimplefe testcases in one place is nice ...
yes, they ICE on targets that do not have vector capabilities:
gimplefe-40.c:7:1: internal compiler error: in emit_move_insn, at
expr.c:3821
Normally we
On Thu, Apr 15, 2021 at 6:50 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> the gimplefe40 and gimplefe41.c tests expect vector capabilities
> (vect_float etc.) yet are not in the vect subdirectory. This causes
> both to be called unconditionally without prior target-specific vector
> setup
47 matches
Mail list logo
