gcc/ChangeLog:
* value-range.h (frange::frange): Add constructor taking type.
---
gcc/value-range.h | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 07a2067898c..9d630e40f78 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -2
We have a set_nan(type) method which can be confused with
update_nan(bool) because of the silent conversion of pointers to bool.
Currently, if you call update_nan(tree), you'll set the possibility of
NAN with a sign of true if tree is non-null. This is prone to error
and this patch disallows this
The methods from which these derive all have a default relation_kind.
This patch just adds the default, to make it easier to write unit
tests later.
gcc/ChangeLog:
* range-op-float.cc: Add relation_kind = VREL_VARYING to all
methods.
---
gcc/range-op-float.cc | 80 +++
gcc/ChangeLog:
* range-op-float.cc (frange_float): New.
(range_op_float_tests): New.
* range-op.cc (range_op_tests): Call range_op_float_tests.
---
gcc/range-op-float.cc | 26 ++
gcc/range-op.cc | 3 +++
2 files changed, 29 insertions(+)
dif
In writing some range-op entries I noticed we don't have a way to
query the sign of the NAN in a range, unless the range only contains
NAN, in which case you can just use frange::signbit_p. This patch
adds a method that returns TRUE if there exists the possiblity of a
NAN and we know its sign.
gc
Hi,
As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
to store into constant pool and ICE occur. But actually, this rtx represents
partial incomplete address and can not be put into a .rodata section.
This patch updates rs6000_cannot_force_const_mem to return true for
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
BR,
Jeff (Jiufu)
Jiufu Guo via Gcc-patches writes:
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
>
> BR,
> Jeff(Jiufu)
>
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> When checking eq/ne with a
> On 12 Oct 2022, at 00:19, Jason Merrill wrote:
>
> 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:
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set p
On Tue, Oct 11, 2022 at 7:52 PM Lulu Cheng wrote:
>
> 在 2022/10/12 上午4:57, Caroline Tice 写道:
>
> 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 ma
On 10/11/22 21:39, Kito Cheng via Gcc-patches wrote:
I would suggest we do not include those header files unless we really need that.
Agreed. Policy is to include what's needed. There's actually some
scripts that will identify extraneous header includes, but I don't
recall if we ever ran
OK. I am gonna commit this with the following patches.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-10-12 11:39
To: juzhe.zhong
CC: gcc-patches
Subject: Re: [PATCH] RISC-V: Refine riscv-vector-builtins.o include files and
makefile.
I would suggest we do not include those header files unles
I would suggest we do not include those header files unless we really need that.
On Tue, Oct 11, 2022 at 2:32 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins.cc: Change include files same as
> ARM SVE.
> * config/riscv/t-riscv: Refine
> -Original Message-
> From: Cui, Lili
> Sent: Wednesday, October 12, 2022 11:00 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com; Lu, Hongjiu
>
> Subject: [PATCH] Remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS
>
> Hi Hontao,
>
> This patch is to remove AVX
Add a soft floating point condition to the register recovery part of the code.
libitm/ChangeLog:
* config/loongarch/sjlj.S: Add a soft floating point condition to the
register recovery part of the code.
---
libitm/config/loongarch/sjlj.S | 3 +++
1 file changed, 3 insertions(+)
Hi gcc-patches,
I had applied the patch below to binutils-gdb, but it recently got wiped
out by a gcc -> binutils-gdb configure.ac sync. Would it be possible to
apply it to the gcc repo so this doesn't happen again?
Thanks,
Simon
On 2022-03-15 17:26, Simon Marchi via Gdb-patches wrote:
> From:
Hi Hontao,
This patch is to remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS.
The new intel ISE removes AVX512_VP2INTERSECT from SAPPHIRERAPIDS,
AVX512_VP2INTERSECT is only supportted in Tigerlake.
Hi Uros,
This patch is to remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS.
The new intel ISE
Pushed to r13-3241
在 2022/9/27 下午10:01, David Malcolm 写道:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of course!
在 2022/10/12 上午4:57, Caroline Tice 写道:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107226
On Wed, Oct 12, 2022 at 9:55 AM Hongtao Liu wrote:
>
> This commit failed tests
>
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c scan-ass
This commit failed tests
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr92645.c scan-tree-dump-times optimized "vec_unpack_" 4
FAIL: gcc.target/i38
On 10/11/22 18:03, Paul Iannetta wrote:
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
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
> -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
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
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 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 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 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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, 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
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 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
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, 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 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
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
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
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
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))
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 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::
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:
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
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.
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,
>
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 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
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 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
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
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.
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
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
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
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
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
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
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
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
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
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
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
在 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 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
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
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 ++
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
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
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 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 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 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 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 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.
>
>
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 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
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: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 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
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, 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
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
1 - 100 of 121 matches
Mail list logo
