On Tue, Feb 22, 2022 at 8:19 PM Andrew MacLeod via Gcc-patches
wrote:
>
> On 2/22/22 13:07, Jeff Law wrote:
> >
> >
> > On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
> >> On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
> That is EH, then there are calls that
On Tue, 22 Feb 2022, Qing Zhao wrote:
> __builtin_clear_padding() will clear all the padding bits of the
> object.
> actually, it doesn't involve any use of an user variable. Therefore, users do
> not expect any uninitialized warning from it. It's reasonable to suppress
> uninitialized warnings
On Tue, Feb 22, 2022 at 5:42 PM Andrew MacLeod via Gcc-patches
wrote:
>
> This patch simply leverages the existing computation machinery to
> re-evaluate values dependent on a newly found non-null value
>
> Ranger associates a monotonically increasing temporal value with every
> def as it is
On Tue, Feb 22, 2022 at 5:42 PM Andrew MacLeod via Gcc-patches
wrote:
>
> Ranger currently waits until the end of the VRP pass, then calls
> export_global_ranges ().
>
> This method walks the list of ssa-names looking for names which it
> thinks should have SSA_NAME_RANGE_INFO updated, and is an
On Tue, 22 Feb 2022, Richard Sandiford wrote:
> Gah, thanks. Clearly one of those days :-(
Looks good to me, thanks.
Gerald
On 2022-02-23 01:30, Segher Boessenkool wrote:
Hi Jiu Fu,
On Tue, Feb 22, 2022 at 02:53:13PM +0800, Jiufu Guo wrote:
static bool
rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED,
rtx x)
{
- if (GET_CODE (x) == HIGH
- && GET_CODE (XEXP (x, 0)) == UNSPEC)
+ if
Hi!
This patch aims to add a warning when casting "this" in a base class
constructor to a derived class type. It works on the test cases
provided, but I'm still running regression tests.
However, I have a few doubts:
1. Am I missing out any cases? Right now, I'm identifying the casts by
checking
On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> On Mon, Feb 21, 2022 at 03:17:46PM -0600, Paul A. Clarke wrote:
> > Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is
> > no
> > longer required.
> >
> > 2021-02-21 Paul A. Clarke
> >
> >
On Mon, Feb 21, 2022 at 03:17:46PM -0600, Paul A. Clarke wrote:
> Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
> longer required.
>
> 2021-02-21 Paul A. Clarke
>
> gcc/testsuite
> * g++.dg/pr65240.h: Move to g++.target/powerpc.
> *
I committed this libgo patch to update the README.gcc file.
Ian
0f16f4ad82cb47bc444688822cc142d80192c284
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 7455d01c179..424bbebfeed 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
I committed ths libgo patch to make -Werror optional. This patch is
already in the GCC sources, where it was erroneously applied before
the upstream patch. This is the upstream patch.
Ian
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 3cadc6d20..7e2b98ba6 100644
---
>> Anyway, I checked what cuda does for HF, and it passes a byte array:
>>> .param .align 2 .b8 _Z5helloPj6__halfs_param_1[2], ...
> >
> > The one precedent that I can point to is that LLVM's nvptx backend passes
> > HFmode values in SImode regs, see https://reviews.llvm.org/D28540
>
>
On Thu, Feb 3, 2022 at 6:07 AM David Seifert via Gcc-patches
wrote:
>
> * `-Werror` can cause issues when a more recent version of GCC compiles
> an older version:
> - https://bugs.gentoo.org/229059
> - https://bugs.gentoo.org/475350
> - https://bugs.gentoo.org/667104
>
>
On 2/22/22 17:08, Roger Sayle wrote:
Hi Tom,
I'll admit that I'd not myself considered the ABI issues when I initially
proposed
experimental HFmode support for the nvptx backend, and was surprised when
I finally tracked down the source of the problem you'd reported: that libgcc
spots HFmode
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template definition time, cp_parser_template_id gets (since r12-6754)
this TYPE_DECL which it can't handle.
This patch defers lookup for implicit typedefs, a
On Tue, Feb 22, 2022 at 12:28:56PM -0600, Segher Boessenkool wrote:
> On Mon, Feb 21, 2022 at 03:17:44PM -0600, Paul A. Clarke wrote:
> > Some tests in g++.dg are target-specific for powerpc. Move those to
> > g++.target/powerpc. Update the DejaGnu directives as needed, since
> > the target
On 2/22/22 13:07, Jeff Law wrote:
On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
That is EH, then there are calls that might not return because they
leave
in some other way (e.g. longjmp), or might loop forever,
Hi Harald,
a recently introduced shape validation for an array constructor
against the declared shape of a DT component failed to punt if
the shape of the constructor cannot be determined at compile time.
Suggested solution: skip the shape check in those cases.
Regtested on
On Mon, Feb 21, 2022 at 03:17:44PM -0600, Paul A. Clarke wrote:
> Some tests in g++.dg are target-specific for powerpc. Move those to
> g++.target/powerpc. Update the DejaGnu directives as needed, since
> the target restriction is perhaps no longer needed when residing in the
> target-specific
Hi!
On Mon, Feb 21, 2022 at 03:17:45PM -0600, Paul A. Clarke wrote:
> Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
> longer required.
>
> 2021-02-21 Paul A. Clarke
>
> gcc/testsuite
> * g++.dg/ext/altivec-1.C: Move to g++.target/powerpc, adjust dg
>
On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
That is EH, then there are calls that might not return because they leave
in some other way (e.g. longjmp), or might loop forever, might exit, might
abort, trap etc.
On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
> > That is EH, then there are calls that might not return because they leave
> > in some other way (e.g. longjmp), or might loop forever, might exit, might
> > abort, trap etc.
> Generally speaking, calls which do not return should
On Tue, Feb 22, 2022 at 2:40 PM Roger Sayle wrote:
>
>
>
> This patch resolves the bootstrap failure on x86_64-pc-linux-gnu.
>
> Is this sufficiently "obvious" in stage4, or should I wait for the bootstrap
>
> and regression testing to complete?
Please just bootstrap the compiler.
>
>
>
On 2/22/22 11:56, Jakub Jelinek wrote:
On Tue, Feb 22, 2022 at 11:39:41AM -0500, Andrew MacLeod wrote:
I'd like to get clarification on some subtle terminology. I find I am
conflating calls that don't return with calls that may throw, and I think
they have different considerations.
My
Hi Jiu Fu,
On Tue, Feb 22, 2022 at 02:53:13PM +0800, Jiufu Guo wrote:
> static bool
> rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
> {
> - if (GET_CODE (x) == HIGH
> - && GET_CODE (XEXP (x, 0)) == UNSPEC)
> + if (GET_CODE (x) == HIGH)
> return true;
__builtin_clear_padding() will clear all the padding bits of the object.
actually, it doesn't involve any use of an user variable. Therefore, users do
not expect any uninitialized warning from it. It's reasonable to suppress
uninitialized warnings for all new created uses from
Hi!
On 2021-08-09T16:16:51+0200, I wrote:
> This concerns a class of ICEs seen as of og10 branch with the
> "openacc: Middle-end worker-partitioning support" and "amdgcn:
> Enable OpenACC worker partitioning for AMD GCN" changes applied:
I've determined that as of commit
On Tue, Feb 22, 2022 at 11:39:41AM -0500, Andrew MacLeod wrote:
> I'd like to get clarification on some subtle terminology. I find I am
> conflating calls that don't return with calls that may throw, and I think
> they have different considerations.
>
> My experiments with calls that can throw
Hi!
On 2021-08-16T12:34:09+0200, I wrote:
> On 2021-08-06T09:49:58+0100, Julian Brown wrote:
>> On Wed, 4 Aug 2021 15:13:30 +0200
>> Thomas Schwinge wrote:
>>
>>> 'oacc_do_neutering' is the 'execute' function of the pass, so that
>>> means every time this executes, a fresh 'field_map' is set
This patch simply leverages the existing computation machinery to
re-evaluate values dependent on a newly found non-null value
Ranger associates a monotonically increasing temporal value with every
def as it is defined. When that value is used, we check if any of the
values used in the
Ranger currently waits until the end of the VRP pass, then calls
export_global_ranges ().
This method walks the list of ssa-names looking for names which it
thinks should have SSA_NAME_RANGE_INFO updated, and is an artifact of
the on-demand mechanism where there isn't an obvious time to
Hi!
On 2021-05-21T16:28:57+0200, I wrote:
> This came into existance internally, when the og10 branch was set up.
>
> On 2020-06-03T17:23:51+0200, Tobias Burnus wrote:
>> This fixes [...] on OG10 (og10_prerelease); it will be
>> later applied to gcn/… to fix the issue. (Upstream is unaffected.)
I'd like to get clarification on some subtle terminology. I find I am
conflating calls that don't return with calls that may throw, and I
think they have different considerations.
My experiments with calls that can throw indicate that they always end a
basic block. This makes sense to me as
Hi Tom,
I'll admit that I'd not myself considered the ABI issues when I initially
proposed
experimental HFmode support for the nvptx backend, and was surprised when
I finally tracked down the source of the problem you'd reported: that libgcc
spots HFmode support exists and immediately starts
Hi Tom,
On 22.02.22 15:43, Tom de Vries wrote:
On 2/17/22 18:24, Tobias Burnus wrote:
--- a/gcc/config/nvptx/t-omp-device
+++ b/gcc/config/nvptx/t-omp-device
@@ -1,4 +1,4 @@
echo kind: gpu > $@
echo arch: nvptx >> $@
-echo isa: sm_30 sm_35 >> $@
+echo isa: sm_30 sm_35 sm_53
On 2/11/22 11:38, Roger Sayle wrote:
This one line fix/tweak is the back-end specific change for a fix for
PR target/104489, that allows the ISA for GCC's nvptx backend to be bumped
to sm_53. The machine-independent middle-end pieces were posted here:
On 2/9/22 21:12, Roger Sayle wrote:
This patch adds middle-end support for target ABIs that pass/return
floating point values in integer registers with precision wider than
the original FP mode. An example, is the nvptx backend where 16-bit
HFmode registers are passed/returned as (promoted to)
From: Christophe Lyon
This patch covers a few non-load/store builtins where we do not use
the iterator and thus we cannot use .
Most of the work of this patch series was carried out while I was
working at STMicroelectronics as a Linaro assignee.
2022-02-22 Christophe Lyon
gcc/
From: Christophe Lyon
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
For v2di instructions, we keep the HI mode for predicates.
Most of the work of this patch series was carried out while I was
working at STMicroelectronics as a Linaro assignee.
From: Christophe Lyon
VPR_REG should be part of ALL_REGS, this patch fixes this omission.
Most of the work of this patch series was carried out while I was
working at STMicroelectronics as a Linaro assignee.
2022-02-22 Christophe Lyon
gcc/
* config/arm/arm.h
From: Christophe Lyon
This is mostly a mechanical change, only tested by the intrinsics
expansion tests.
Most of the work of this patch series was carried out while I was
working at STMicroelectronics as a Linaro assignee.
2022-02-22 Christophe Lyon
gcc/
PR target/100757
From: Christophe Lyon
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type.
This patch fixes it by implementing TARGET_VECTORIZE_GET_MASK_MODE,
returning
From: Christophe Lyon
We make use of qualifier_predicate to describe MVE builtins
prototypes, restricting to auto-vectorizable vcmp* and vpsel builtins,
as they are exercised by the tests added earlier in the series.
Special handling is needed for mve_vpselq because it has a v2di
variant, which
From: Christophe Lyon
This patch implements support for vectors of booleans to support MVE
predicates, instead of HImode. Since the ABI mandates pred16_t (aka
uint16_t) to represent predicates in intrinsics prototypes, we
introduce a new "predicate" type qualifier so that we can map relevant
From: Christophe Lyon
This is v4 of this patch series, fixing issues I discovered before
committing v2 (which had been approved). I am posting it for the
record of what I am going commit after I implemented all the requested
changes to v3.
Thanks a lot to Richard Sandiford for his help.
Most
From: Christophe Lyon
This patch mainly adds Neon tests similar to existing MVE ones,
to make sure we do not break Neon when fixing MVE.
mve-vcmp-f32-2.c is similar to mve-vcmp-f32.c but uses a conditional
with 2.0f and 3.0f constants to help scan-assembler-times.
Most of the work of this
From: Christophe Lyon
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
Most of the work of this patch series was carried out while I was
working at STMicroelectronics as a Linaro assignee.
2022-02-22 Christophe Lyon
gcc/
From: Christophe Lyon
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not seem to require this anymore, but it
seems
From: Christophe Lyon
VPR_REG is the only register in its class, so it should be handled by
TARGET_CLASS_LIKELY_SPILLED_P, which is achieved by calling
default_class_likely_spilled_p. No test fails without this patch, but
it seems it should be implemented.
Most of the work of this patch series
On 5/19/21 16:52, Tom de Vries wrote:
On 4/23/21 6:48 PM, Tom de Vries wrote:
On 4/23/21 5:45 PM, Alexander Monakov wrote:
On Thu, 22 Apr 2021, Tom de Vries wrote:
Ah, I see, agreed, that makes sense. I was afraid there was some
fundamental problem that I overlooked.
Here's an updated
On 2022-02-20 12:34, Iain Sandoe wrote:
^^^ this is mostly for my education - the stuff below is a potential solution
to leaving lra-constraints unchanged and fixing the Darwin bug….
I'd be really glad if you do manage to fix this w/o changing LRA.
Richard has a legitimate point that my
On 2/17/22 18:24, Tobias Burnus wrote:
diff --git a/gcc/config/nvptx/t-omp-device b/gcc/config/nvptx/t-omp-device
index 8765d9f1881..4228218a424 100644
--- a/gcc/config/nvptx/t-omp-device
+++ b/gcc/config/nvptx/t-omp-device
@@ -1,4 +1,4 @@
omp-device-properties-nvptx:
On 2/17/22 18:24, Tobias Burnus wrote:
SM version (-misa=)
[Patch adds -misa=sm_70]
* The compiler supports internally: SM_30, SM_35, SM_53, SM_70, SM_75,
SM_80.
I'd formulate it like: it uses SM_70 internally to accurately formulate
when certain insns can be used.
I think it makes sense
On 2/17/22 18:24, Tobias Burnus wrote:
PTX version (-mptx=)
[patch adds -mptx=6.0 as option]
* Currently supported internally are 3.1 (CUDA 5.0, used by GCC <= 11),
6.0 (CUDA 9.0, current GCC 12 default), 6.3 (CUDA 10.0), 7.0 (CUDA 11.0)
* -mptx= supports 3.1, 6.3, 7.0 – but not the internal
On Mon, Feb 21, 2022 at 6:43 PM Hongtao Liu wrote:
>
> On Tue, Feb 22, 2022 at 2:35 AM H.J. Lu wrote:
> >
> > On Sun, Feb 20, 2022 at 6:01 PM Hongtao Liu wrote:
> > >
> > > On Thu, Feb 17, 2022 at 9:56 PM H.J. Lu wrote:
> > > >
> > > > On Thu, Feb 17, 2022 at 08:51:31AM +0100, Uros Bizjak
Hi,
For the nvptx port, with -mptx-comment we have in pr53465.s:
...
// #APP
// 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1
// Start: Added by -minit-regs=3:
// #NO_APP
mov.u32 %r26, 0;
// #APP
// 9
Hi,
Add functionality that indicates which insns are added by -minit-regs, such
that for instance we have for pr53465.s:
...
// #APP
// 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1
// Start: Added by -minit-regs=3:
// #NO_APP
mov.u32 %r26, 0;
This patch resolves the bootstrap failure on x86_64-pc-linux-gnu.
Is this sufficiently "obvious" in stage4, or should I wait for the bootstrap
and regression testing to complete?
2022-02-22 Roger Sayle
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop): Restore
This makes the SLP vectorizer dump the def we use for a splat to
aid debugging.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-02-22 Richard Biener
* tree-vect-slp.cc (vect_build_slp_tree_2): Dump the def used
for a splat.
---
gcc/tree-vect-slp.cc | 3 ++-
Hi Ian,
> On Sun, Feb 20, 2022 at 2:13 PM Rainer Orth
> wrote:
>>
>> > This patch updates libgo to the Go1.18rc1 release. Bootstrapped and
>> > ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
>>
>> this broke Solaris bootstrap:
>>
>> ld: fatal: file
This patch resolves PR c++/96442, another ICE-after-error regression.
In this case, invalid code attempts to use a non-integral type as the
underlying type for an enumeration (a record_type in the example given
in the bugzilla PR), for which the parser emits an error message but
allows the
On Tue, Feb 22, 2022 at 7:39 AM Cui,Lili wrote:
>
> Hi Uros,
>
> This patch is to update Intel architectures ISA support in documentation.
> Since the ISA supported by Intel architectures in the documentation
> are inconsistent with the actual, modify them all.
>
> OK for master?
OK.
Thanks,
Jakub Jelinek writes:
> On Tue, Feb 22, 2022 at 10:11:06AM +, Richard Sandiford via Gcc-patches
> wrote:
>> Document ShadowCallStack support. The option link doesn't work yet
>> of course, but I checked that it works with gcc-12.1.0/ removed.
>>
>> OK to install?
>>
>> Thanks,
>> Richard
On Tue, 22 Feb 2022, Richard Sandiford wrote:
> Err, scratch that. Clearly I've not had tea this morning, and forgot
> which version we're about to release :-)
No worries! (And it's not even 13 yet. ;-)
For the record, I for one am happy for you to make such changes
as you see fit (where
On Tue, Feb 22, 2022 at 10:11:06AM +, Richard Sandiford via Gcc-patches
wrote:
> Document ShadowCallStack support. The option link doesn't work yet
> of course, but I checked that it works with gcc-12.1.0/ removed.
>
> OK to install?
>
> Thanks,
> Richard
>
>
> ---
>
On Tue, 22 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> On
> #define A(n) int foo1##n(void) { return 1##n; }
> #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
> A(n##8) A(n##9)
> #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
> B(n##8)
Document ShadowCallStack support. The option link doesn't work yet
of course, but I checked that it works with gcc-12.1.0/ removed.
OK to install?
Thanks,
Richard
---
htdocs/gcc-12/changes.html | 11 +++
1 file changed, 11 insertions(+)
diff --git a/htdocs/gcc-12/changes.html
Hi!
On
#define A(n) int foo1##n(void) { return 1##n; }
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4)
On Tue, 22 Feb 2022, Richard Biener wrote:
> On Tue, 22 Feb 2022, Hongtao Liu wrote:
>
> > On Mon, Feb 21, 2022 at 5:10 PM Richard Biener wrote:
> > >
> > > On Mon, 21 Feb 2022, Hongtao Liu wrote:
> > >
> > > > On Fri, Feb 18, 2022 at 10:01 PM Richard Biener via Gcc-patches
> > > > wrote:
> >
Richard Sandiford writes:
> Group the ThreadSanitizer and HardwareAssistedAddressSanitizer
> changes under a single top-level bullet point. This makes it
> easier to add a third sanitiser-related change.
>
> No (intended) change to the actual text or wording. (TBH I don't
> understand the
Group the ThreadSanitizer and HardwareAssistedAddressSanitizer
changes under a single top-level bullet point. This makes it
easier to add a third sanitiser-related change.
No (intended) change to the actual text or wording. (TBH I don't
understand the ThreadSanitizer bit: is it describing three
Hi,
When running the libgomp testsuite on x86_64 with nvptx accelerator, we run
into:
...
XPASS: libgomp.c/../libgomp.c-c++-common/pr96390.c (test for excess errors)
FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test
...
The problem is that we're expecting the following ptxas
Hi,
On nvptx I see the following FAIL:
...
FAIL: gcc.dg/sibcall-3.c execution test
...
The test-case states that "this test is xfailed on targets without sibcall
patterns".
The nvptx port doesn't have a sibcall pattern, so add an xfail. Likewise in
two similar test-cases.
Tested on nvptx.
Hi,
Some test-cases in gcc/testsuite/gcc.target/nvptx contain mptx
settings, which are paired with misa settings, in order to have the mptx
version support the misa version.
Since commit decde11183bd ("[nvptx] Choose -mptx default based on -misa"),
this is no longer necessary.
Remove the mptx
74 matches
Mail list logo
