On Mon, 10 Oct 2022, Andrew Stubbs wrote:
> On 10/10/2022 12:03, Richard Biener wrote:
> > The following picks up the prototype by Ju-Zhe Zhong for vectorizing
> > first order recurrences. That solves two TSVC missed optimization PRs.
> >
> > There's a new scalar cycle def kind, vect_first_order
On Thu, Oct 6, 2022, 17:56 Jonathan Wakely wrote:
> > I actually just copy-pasted the header from another test, would it be
> simpler if i just removed it?
>
>
> Yes, that's probably the simplest solution, and then add a
> Signed-off-by: tag in your patch email, to state you're contributing
> it
> On 10 Oct 2022, at 21:38, Jonathan Wakely wrote:
>
> On Mon, 10 Oct 2022 at 19:06, Olivier Hainque via Libstdc++
> wrote:
>>
>> Sorry, I forgot to cc libstdc++ on
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html
>>
>> which includes a regen of libstdc++-v3/config
Hi,
This patch modifies the help function which generates permute index for
vector byte reversion and generates permute index directly for little endian
targets. It saves one "xxlnor" instructions on P8 little endian targets as
the original process needs an "xxlnor" to calculate complement for th
On Okt 10 2022, Marek Polacek via Gcc-patches wrote:
> diff --git a/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> b/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> new file mode 100644
> index 000..975885462e9
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> @@ -0,0 +1,
For genereal_reg_operand, it will be splitted into xor + not.
For mask_reg_operand, it will be splitted with UNSPEC_MASK_OP just
like what we did for other logic operations.
The patch will optimize xor+not to kxnor when possible.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
Ok for trunk?
g
When solving 0 = _15 & 1, we calculate _15 as:
[irange] int [-INF, -2][0, +INF] NONZERO 0xfffe
The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with
the above, yielding:
[0, 1] NONZERO 0x0
This eventually gets copied to a _Bool [0, 1] NONZERO 0x0.
This is p
Hi, I apply this patch in RVV downstrean. Tested it with a lot of vector
benchmark. It overal has a greate performance gain.
Maybe the last thing to merge this patch is wait for Richard Sandiford test it
in ARM SVE?
By the way, would you mind sharing the case list that GCC failed to vectorize
b
Richard Biener writes:
> On Mon, 10 Oct 2022, Andrew Stubbs wrote:
>> On 10/10/2022 12:03, Richard Biener wrote:
>> > The following picks up the prototype by Ju-Zhe Zhong for vectorizing
>> > first order recurrences. That solves two TSVC missed optimization PRs.
>> >
>> > There's a new scalar cy
On Tue, Oct 11, 2022 at 10:03 AM liuhongt wrote:
>
> For genereal_reg_operand, it will be splitted into xor + not.
> For mask_reg_operand, it will be splitted with UNSPEC_MASK_OP just
> like what we did for other logic operations.
>
> The patch will optimize xor+not to kxnor when possible.
>
> Boo
On Mon, 2022-10-10 at 10:49 -0700, Caroline Tice via Gcc-patches wrote:
> Is "if (VTV_PAGE_SIZE != sysconf (_SC_PAGE_SIZE))" going to fail for
> loongarch?
Because LoongArch systems may have 4KB, 16KB, or 64KB pages.
> If not, why do you need to insert anything here at all? If so,
> perhaps you
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, October 10, 2022 4:30 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Subject: Re: [PATCH][GCC 12] arm: Fix constant immediates predicates and
> constraints for some MVE builtins
>
> ping^2 ?
>
>
> On 10/5/22 16:55, Chri
On Fri, Oct 07, 2022 at 04:26:58PM +0200, Tobias Burnus wrote:
> libgomp/nvptx: Prepare for reverse-offload callback handling
>
> This patch adds a stub 'gomp_target_rev' in the host's target.c, which will
> later handle the reverse offload.
> For nvptx, it adds support for forwarding the offload
On 07/10/2022 13:45, Jørgen Kvalsvik wrote:
> On 07/10/2022 08:53, Richard Biener wrote:
>> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
>> wrote:
>>>
>>> On 06/10/2022 10:12, Richard Biener wrote:
On Wed, Oct 5, 2022 at 2:49 PM Martin Liška wrote:
>
> On 10/5/22 14:04, Jørgen Kval
This patch series adds additional vector sizes for the amdgcn backend.
The hardware supports any arbitrary vector length up to 64-lanes via
masking, but GCC cannot (yet) make full use of them due to middle-end
limitations. Adding smaller "virtual" vector sizes increases the
complexity of the back
GET_MODE_NUNITS isn't a compile time constant, so we end up with many
impossible insns in the machine description. Adding MODE_VF allows the insns
to be eliminated completely.
gcc/ChangeLog:
* config/gcn/gcn-valu.md
(2): Use MODE_VF.
(2): Likewise.
* config/gcn/g
Add vec_extract expanders for all valid pairs of vector types.
gcc/ChangeLog:
* config/gcn/gcn-protos.h (get_exec): Add prototypes for two variants.
* config/gcn/gcn-valu.md
(vec_extract): New define_expand.
* config/gcn/gcn.cc (get_exec): Export the existing func
Implements vec_init when the input is a vector of smaller vectors, or of
vector MEM types, or a smaller vector duplicated several times.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (vec_init): New.
* config/gcn/gcn.cc (GEN_VN): Add andvNsi3, subvNsi3.
(GEN_VNM): Add gathervNm
The vectors sizes are simulated using implicit masking, but they make life
easier for the autovectorizer and SLP passes.
gcc/ChangeLog:
* config/gcn/gcn-modes.def (VECTOR_MODE): Add new modes
V32QI, V32HI, V32SI, V32DI, V32TI, V32HF, V32SF, V32DF,
V16QI, V16HI, V16SI, V16
Another example of the vectorizer needing explicit insns where the scalar
expander just works.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (neg2): New define_expand.
---
gcc/config/gcn/gcn-valu.md | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/config/gcn/gcn-valu.md
The testsuite needs a few tweaks following my patches to add multiple vector
sizes for amdgcn.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104464.c: Xfail on amdgcn.
* gcc.dg/signbit-2.c: Likewise.
* gcc.dg/signbit-5.c: Likewise.
* gcc.dg/vect/bb-slp-68.c: Likewise.
On Tue, 11 Oct 2022 at 07:41, Richard Biener wrote:
>
> On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely wrote:
> >
> > On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely wrote:
> > >
> > > On Mon, 10 Oct 2022 at 07:18, Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Oct 7, 2022 at 5:55 PM Jonat
On Tue, 11 Oct 2022, Jakub Jelinek wrote:
> So, does this mean one has to have gcc configured --with-arch=sm_70
> or later to make reverse offloading work (and then on the other
> side no support for older PTX arches at all)?
> If yes, I was kind of hoping we could arrange for it to be more
> user
The following fixes an issue with how we handle epilogue generation
for SLP reductions of reduction paths where the actual live lanes
are not "canonical". We need to make sure to identify all live
lanes as reductions and thus have to iterate over all participating
SLP lanes when walking the reduct
On Tue, Oct 11, 2022 at 12:57 PM Jørgen Kvalsvik
wrote:
>
> On 07/10/2022 13:45, Jørgen Kvalsvik wrote:
> > On 07/10/2022 08:53, Richard Biener wrote:
> >> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
> >> wrote:
> >>>
> >>> On 06/10/2022 10:12, Richard Biener wrote:
> On Wed, Oct 5, 2022
On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
>
> This patch series adds additional vector sizes for the amdgcn backend.
>
> The hardware supports any arbitrary vector length up to 64-lanes via
> masking, but GCC cannot (yet) make full use of them due to middle-end
> limitations. Adding sm
On Tue, Oct 04, 2022 at 21:12:03 +0200, Harald Anlauf wrote:
> Am 04.10.22 um 17:12 schrieb Ben Boeckel:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper order.
On Tue, Oct 11, 2022 at 1:06 PM Jonathan Wakely wrote:
>
> On Tue, 11 Oct 2022 at 07:41, Richard Biener
> wrote:
> >
> > On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely wrote:
> > >
> > > On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely wrote:
> > > >
> > > > On Mon, 10 Oct 2022 at 07:18, Richard
The grammar for a lambda context can include 'M', and we
were adding the component that generated to the substitution table
twice. Just ignore the 'M' completely -- we'll already have done the
checks we need when we saw its predecessor. A prefix cannot be the
last component of a nested name, s
On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> On 10/4/22 11:12, Ben Boeckel wrote:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper order.
>
>
On 11/10/2022 12:29, Richard Biener wrote:
On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
This patch series adds additional vector sizes for the amdgcn backend.
The hardware supports any arbitrary vector length up to 64-lanes via
masking, but GCC cannot (yet) make full use of them due t
On Oct 10, 2022, Richard Biener wrote:
> As noted in the Cauldron Discussion I think you should do all
> instrumentation post-IPA only to simplify your life not needing to
> handle inlining of instrumentation
I looked a bit into that after the Cauldron, and recalled why I wanted
to instrument be
On Tue, Oct 11, 2022 at 1:53 PM Andrew Stubbs wrote:
>
> On 11/10/2022 12:29, Richard Biener wrote:
> > On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
> >>
> >> This patch series adds additional vector sizes for the amdgcn backend.
> >>
> >> The hardware supports any arbitrary vector length
On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
>
> On Oct 10, 2022, Richard Biener wrote:
>
> > As noted in the Cauldron Discussion I think you should do all
> > instrumentation post-IPA only to simplify your life not needing to
> > handle inlining of instrumentation
>
> I looked a bit in
On Thu, Jan 13, 2022 at 02:53:16PM +, Hafiz Abid Qadeer wrote:
> Currently we only make use of this directive when it is associated
> with an allocate statement.
Sorry for the delay.
I'll start with a comment that allocate directive in 5.0/5.1
for Fortran is a complete mess that has been fixe
On Thu, Jan 13, 2022 at 02:53:17PM +, Hafiz Abid Qadeer wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
> (gfc_trans_omp_allocate): New function.
> (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
>
> gcc/ChangeLog
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
$ diff --git a/gc
Add a test to catch regression in line counts for labels on top of
then/else blocks. Only the 'goto ' should contribute to the line
counter for the label, not the if.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-4.c:
---
gcc/testsuite/gcc.misc-tests/gcov-4.c | 26 ++
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
r.dump (dump_file);
fputc ('\n', dump_file);
}
Andrew
On 10/10/22 14:58, Aldy Hernandez wrote:
[Andrew, you OK with this? I c
Hi Jakub,
On 11.10.22 14:24, Jakub Jelinek wrote:
There is another issue besides what I wrote in my last review,
and I'm afraid I don't know what to do about it, hoping Tobias
has some ideas.
The problem is that without the allocate-stmt associated allocate directive,
Fortran allocatables are ea
在 2022-10-10 23:56, LIU Hao 写道:
在 2022-10-04 20:44, LIU Hao 写道:
Attached are revised patches. These are exported from trunk.
Revised further. The patch for libgfortran has been committed to trunk today, so I include only the
other two.
* In the second patch, a space character has been i
Hi!
The following patch implements excess precision support for C++.
Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand
is evaluated in excess precision and what the semantic type of the
expression is.
In most places I've followed what the C FE does in similar spots, so
e.g. fo
On Oct 11, 2022, Richard Biener wrote:
> On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
>>
>> On Oct 10, 2022, Richard Biener wrote:
>>
>> > As noted in the Cauldron Discussion I think you should do all
>> > instrumentation post-IPA only to simplify your life not needing to
>> > handl
On Mon, Oct 10, 2022 at 11:19:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote:
> > On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
> > > My earlier patches gimplify the simplest non-side-effects assumptions
> > > into if (cond
It's incredibly annoying that some of the BRS_TRUE cases come after
BRS_FALSE, if only because we're not consistent. Having random
ordering increases the changes of thinkos when adapting the irange
code to floats.
gcc/ChangeLog:
* range-op.cc (operator_equal::op1_range): Move BRS_TRUE ca
Most unordered comparisons can use the result from the ordered
version, if the operands are known not to be NAN or if the result is
true.
gcc/ChangeLog:
* range-op-float.cc (class foperator_unordered_lt): New.
(class foperator_relop_unknown): Remove
(class foperator_unorde
Implementing ABS_EXPR allows us to fold certain __builtin_inf calls
since they are expanded into calls to involving ABS_EXPR.
This is an adaptation of the integer version.
gcc/ChangeLog:
* range-op-float.cc (class foperator_abs): New.
(floating_op_table::floating_op_table): Add A
gcc/ChangeLog:
* range-op-float.cc (foperator_unordered_le::op1_range): New.
(foperator_unordered_le::op2_range): New.
(foperator_unordered_gt::op1_range): New.
(foperator_unordered_gt::op2_range): New.
(foperator_unordered_ge::op1_range): New.
(fope
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should c
I forgot to mention. These were lifted from the integer counterparts.
Most of the code is the same, as the build_{cond} code in the frange
version will add the appropriate NAN (unless -ffinite-math-only), and
all we have to do is clear it on the false edge.
Aldy
On Tue, Oct 11, 2022 at 3:51 PM A
On 11/10/2022 15:55, Michael Matz wrote:
> Hello,
>
> On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
>
>> The coverage support will under some conditions decide to split edges to
>> accurately report coverage. By running the test suite with/without this
>> edge splitting a small diff
On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * config/i386/i386.md (*notxor_1): New post_reload
> define_insn_and_split.
> (*notxorqi_1): Ditto.
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -10826,6 +10826
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik wrote:
> I apologise for the confusion. The diff there is not a part of the
> change itself (note the indentation) but rather a way to reproduce,
Ah! Thanks, that explains it, sorry for adding confusion on top :-)
Ciao,
Michael.
Sure.
OK?
Aldy
On Tue, Oct 11, 2022 at 3:11 PM Andrew MacLeod wrote:
>
> It probably should just be changed to a print if it doesn't return..
> something like
>
> if (idx && res)
>{
> tracer.print (idx, "logical_combine produced");
> r.dump (dump_file);
> fputc ('\n', dump_fil
On Tue, Oct 11, 2022 at 03:22:02PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 11.10.22 14:24, Jakub Jelinek wrote:
>
> There is another issue besides what I wrote in my last review,
> and I'm afraid I don't know what to do about it, hoping Tobias
> has some ideas.
> The problem is that withou
On Tue, Oct 11, 2022 at 04:15:25PM +0200, Jakub Jelinek wrote:
> Well, it can use a weak symbol, if not linked against libgomp, the bit
> that it is OpenMP shouldn't be set and so realloc/free will be used
> and do
> if (arrdescr.gomp_alloced_bit)
> GOMP_free (arrdescr.data, 0);
> else
>
On 11.10.22 16:15, Jakub Jelinek wrote:
I think the most common case is:
integer, allocatable :: var(:)
!$omp allocators allocator(my_alloc) ! must be in same scope as decl of 'var'
...
! optionally: deallocate(var)
end ! of scope: block/subroutine/... - automatic deallocation
So you talk her
perfect.
On 10/11/22 10:08, Aldy Hernandez wrote:
Sure.
OK?
Aldy
On Tue, Oct 11, 2022 at 3:11 PM Andrew MacLeod wrote:
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
r.dump
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
> On 10/4/22 13:36, Patrick Palka wrote:
> > Here when lazily loading the binding for f at parse time from the
> > template g, processing_template_decl is set and thus the call to
> > note_vague_linkage_fn from module_state::read_cluster has no effect,
>
Hello, is there any update regarding the patch PR105387 for bug 105387? We've
been waiting for some time now, but the bugzilla bug is still open:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105387. If there is any issue with
the patch (besides the ones we discussed before), please let us know.
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
{
/* It contains an exported thin
This test fails on non-i?86/x86_64 targets because on those targets
we get
error: '-fcf-protection=full' is not supported for this target
so this patch limits where the test is run.
Tested on x86_64-pc-linux-gnu, ok for trunk?
gcc/testsuite/ChangeLog:
* c-c++-common/pointer-to-fn1.c:
On 10/11/22 10:58, Patrick Palka wrote:
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
On 10/4/22 13:36, Patrick Palka wrote:
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from module_state::
Hi
Now that pretty printer is fixed (once patch validated) I'd like to
propose this patch again.
Note that I'am adding a check on pretty printer with a std::any on
a std::wstring. I did so because of the FIXME in printers.py which is
dealing with 'std::string' explicitely. Looks like
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
Hi!
My earlier patches gimplify the simplest non-side-effects assumptions
into if (cond) ; else __builtin_unreachable (); and throw the rest
on the floor.
The following patch attempts to do something with the rest too.
For -O0, it actuall
This patch seems to have broken bootstrap on AIX. It seems to assume
methods that aren't guaranteed to be defined.
Thanks, David
libtool: compile: /tmp/GCC/./gcc/xgcc -B/tmp/GCC/./gcc/
-B/nasfarm/edelsohn/ins
tall/GCC/powerpc-ibm-aix7.2.5.0/bin/
-B/nasfarm/edelsohn/install/GCC/powerpc-ibm
-aix7
Dear all,
this PR is an obvious followup to PR107000, where invalid
types appeared in array constructors and lead to an ICE
either in a conversion or reduction of a unary or binary
expression.
The present PR shows that several other conversions need to
be protected by a check of the type of the s
Hi Guillermo,
On 10/3/22 7:39 AM, Guillermo E. Martinez via Gcc-patches wrote:
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index 9773358a475..253c36b6a0a 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -604,6 +604,7 @@ ctf_add_enum (ctf_container_ref ctfc, uint32_t
flag, const char * name,
gcc_as
On Tue, 11 Oct 2022, 19:38 David Edelsohn via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> This patch seems to have broken bootstrap on AIX. It seems to assume
> methods that aren't guaranteed to be defined.
>
It doesn't use anything that wasn't already used by that file.
I have no idea how it
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide programmatic implementation of CAS
As both are very related, I
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide p
On Tue, 11 Oct 2022 at 03:51, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk? (The paper
> also makes changes to views::take and views::drop, which will be
> implemented separately.)
OK, thanks.
On Tue, 11 Oct 2022 at 19:58, Jonathan Wakely wrote:
>
>
>
> On Tue, 11 Oct 2022, 19:38 David Edelsohn via Libstdc++,
> wrote:
>>
>> This patch seems to have broken bootstrap on AIX. It seems to assume
>> methods that aren't guaranteed to be defined.
>
>
>
> It doesn't use anything that wasn't a
Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test. At this point
start_preparsed_function hasn't yet set current_function_decl.
expand_vec_init_expr then leads to maybe_splice_retval_cleanup which
checks DECL_CONSTRUCTOR_P (curr
On Tue, Oct 11, 2022 at 09:40:45AM +0200, Andreas Schwab via Gcc-patches wrote:
> On Okt 10 2022, Marek Polacek via Gcc-patches wrote:
>
> > diff --git a/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> > b/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> > new file mode 100644
> > index 000..9
Le 11/10/2022 à 20:47, Harald Anlauf via Fortran a écrit :
Dear all,
this PR is an obvious followup to PR107000, where invalid
types appeared in array constructors and lead to an ICE
either in a conversion or reduction of a unary or binary
expression.
The present PR shows that several other con
Dear all,
we need to check that the operands of arithmetic binary operations
are consistent and of numeric type.
The PR reported an issue for multiplication ("*"), but we better
extend this to the other binary operations.
I chose the following solution:
- consistent types for +,-,*,/, keeping an
On 10/11/22 16:00, Marek Polacek wrote:
Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test.
Hmm, why are we calling cxx_eval_vec_init during parsing of the default
argument? In particular, any expansion that depends on the e
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
> On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> > Hi Christoph, Kito,
> >
> > On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
> >> This series provides a cleanup of the current atomics implementation
> >> of RISC-V
I think that if VTV_PAGE_SIZE is not set to the actual size being used by
the system, it could result in some unexpected failures. I believe the
right thing to do in this case, since the size may vary, is to get the
actual size being used by the system and use that in the definition of
VTV_PAGE_S
I found this when reading the documentation for Kito's recent patch.
>From the discussion it sounds like this is the desired behavior, so
let's document it.
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention __align__
---
gcc/doc/invoke.texi | 4 +++-
1 file changed, 3 insertio
There were some recent discussions about the desired behavior of
-falign-functions, which is behaving as desired. This improves the
documentation to make that explicit.
Change since v1 <20221007134901.5078-1-pal...@rivosinc.com>:
* New patch 2 and 3
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention cold/size-optimized
functions.
---
gcc/doc/invoke.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a24798d5029..6af18ae9bfd 100644
--- a/gcc/doc/i
On Sun, 09 Oct 2022 23:07:21 PDT (-0700), richard.guent...@gmail.com wrote:
On Fri, Oct 7, 2022 at 3:50 PM Palmer Dabbelt wrote:
I found this when reading the documentation for Kito's recent patch.
From the discussion it sounds like this is the desired behavior, so
let's document it.
Maybe a
This is implicitly mentioned in the docs, but there were some questions
in a recent patch. This makes it more exlicit that -falign-functions is
meant to be ignored under -Os.
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention -Os
---
gcc/doc/invoke.texi | 3 ++-
1 file changed
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on target exprs. The code here has a mixture of APIs used
to build inits. This patch changes that to use cp_build_init_expr() where
possible, s
Thank you very much for the comments.
On Mon, Oct 10, 2022 at 03:20:13PM -0400, Jason Merrill wrote:
> On 10/9/22 12:12, Paul Iannetta wrote:
> > That's a nice feature! LLVM is using AS to mangle the
> > address-name qualified types but that would have required an update of
> > libiberty's demangl
On 10/11/22 17:58, Iain Sandoe wrote:
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on target exprs. The code here has a mixture of APIs used
to build inits. This patch changes that to us
On Tue, Oct 11, 2022 at 5:03 PM Palmer Dabbelt wrote:
>
> This is implicitly mentioned in the docs, but there were some questions
> in a recent patch. This makes it more exlicit that -falign-functions is
> meant to be ignored under -Os.
>
> gcc/doc/ChangeLog
>
> * invoke.texi (-falign-fun
Hi Jason
> On 11 Oct 2022, at 23:06, Jason Merrill wrote:
>
> On 10/11/22 17:58, Iain Sandoe wrote:
>> Tested on x86_64-darwin19, OK for master?
>> thanks
>> Iain
>> -- >8 --
>> Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
>> is set properly on target exprs. The code
The SPARC/Linux port is very similar to the SPARC/Solaris port nowadays so it
makes sense to copy the setting of the support for atomic primitives.
This fixes the single regression in the gnat.dg testsuite:
FAIL: gnat.dg/prot7.adb (test for excess errors)
Tested on SPARC64/Linux, applied on the
Hi,
the recent optimization implemented for complex modes in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595865.html
contains an oversight for big-endian platforms in the "interesting corner
case" mentioned in the message: it uses a lowpart SUBREG when the integer
modes have different
On 10/11/22 13:31, Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences
On Mon, Oct 10, 2022 at 11:07:06PM +, Joseph Myers wrote:
> On Mon, 10 Oct 2022, Paul Iannetta via Gcc-patches wrote:
>
> > I have a patch to bring this feature to the C front-end as well, and
> > would like to hear your opinion on it, especially since it may affect
> > the feature-set of the
On 10/11/22 18:17, Iain Sandoe wrote:
Hi Jason
On 11 Oct 2022, at 23:06, Jason Merrill wrote:
On 10/11/22 17:58, Iain Sandoe wrote:
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on targe
On 10/11/22 13:46, Christoph Müllner wrote:
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
>> This series provides a c
On Tue, 11 Oct 2022 16:31:25 PDT (-0700), Vineet Gupta wrote:
On 10/11/22 13:46, Christoph Müllner wrote:
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36, Christoph M
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, October 11, 2022 9:59 PM
> To: Liu, Hongtao
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [x86] Add define_insn_and_split to support general
> version of "kxnor".
>
> On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-c.cc: Add new line.
* config/riscv/riscv_vector.h (vwrite_csr): Add new line.
---
gcc/config/riscv/riscv-c.cc | 2 +-
gcc/config/riscv/riscv_vector.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
1 - 100 of 121 matches
Mail list logo
