On Thu, 25 Feb 2021, Tamar Christina wrote:
> Hi All,
>
> The given testcase shows that one of the children of the complex MUL contains
> a
> PHI node. This results in the vectorizer having a child that's (nil).
>
> The pattern matcher handles this correctly, but optimize_load_redistribution_1
This avoids doing bitfield stores into the return object of calls
when using return-slot optimization and the type is addressable.
Instead we have to pass down the original target RTX to the call
expansion which otherwise tries to create a new temporary.
Bootstrapped and tested on x86_64-unknonw-l
I'm getting this link failure for all compilers:
analyzer/diagnostic-manager.o: In function
`ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph const&)':
diagnostic-manager.cc:(.text+0xd350): undefined reference to
`ana::exploded_path::exploded_path(ana::exploded_path const&)'
On Fri, Feb 26, 2021 at 09:40:05AM +0100, Richard Biener wrote:
> This avoids doing bitfield stores into the return object of calls
> when using return-slot optimization and the type is addressable.
> Instead we have to pass down the original target RTX to the call
> expansion which otherwise tries
It's possible for an aggregate to be declared in a non-default address
space, but the tree pretty-printer doesn't currently show that address
space in dumps, which can be confusing. This patch adds printing of
"" markers for aggregates in non-default address spaces.
OK (now or for stage 1)?
Than
This patch adds warnings for strange partitioning choices -- specifying
either more or fewer partitioning levels on a parallel directive than the
enclosed offload region actually uses.
We've used a version of this patch on the og8/og9/og10 branches for
quite a while. Versions have been posted for
This series contains a rebased/updated/bug-fixed version of the patch
to place gang-local variables in GPU shared memory, last posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534551.html
Further commentary on individual patches. I am posting this for review
now, but I would
This patch updates the TARGET_GOACC_ADJUST_PRIVATE_DECL target hook in
the AMD GCN backend to the current name and prototype. (An earlier
version of the hook was already present, but dormant.)
(I can self-approve this. I will commit as/when the previous patch
is approved.)
Thanks,
Julian
gcc/
This patch implements a method to track the "private-ness" of
OpenACC variables declared in offload regions in gang-partitioned,
worker-partitioned or vector-partitioned modes. Variables declared
implicitly in scoped blocks and those declared "private" on enclosing
directives (e.g. "acc parallel")
This patch contains the NVPTX backend support for placing OpenACC
gang-private variables in GPU shared memory.
Tested with offloading to NVPTX.
This is substantially the same as the version previously posted: I will
assume it is already approved (unless I hear objections), and will commit
it at t
With the understanding that we have preapproval to install testsuite
patches that add misisng fpic requires, I'm going ahead and installing
this patch. I've tested it on x86_64-linux-gnu and on ppc64-vx7r2.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/compress-float-ppc-pic.c: Ad
On Fri, Feb 5, 2021 at 2:59 PM Arnaud Charlet wrote:
>
> > > We'd rather not have PR references in the source files, so please remove
> > > it
> > > (it will be there as part of the commit log and git annotate).
> > >
> > > OK with the comment updated.
> >
> > Thanks, here's the revised patch.
>
Hi,
this wrong-code PR for the C++ compiler on x86-64/Windows is a regression
in GCC 9 and later, but the underlying issue has probably been there since
SEH was implemented and is exposed by this comment in config/i386/winnt.c:
/* SEH records saves relative to the "current" stack pointer, wheth
revert just-added duplicate fpic target requirement
A moment after pushing the previous patch, I noticed the fpic target
requirement markers had already been added to some of the files in the
patch from long ago that I've just contributed. This patch reverts
the duplicates.
for gcc/testsuite/C
ints can be used as futex on Linux. ptrdiff_t on 64-bit Linux can't.
---
libstdc++-v3/include/std/latch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/std/latch b/libstdc++-v3/include/std/latch
index ef8c301e5e9..156aea5c5e5 100644
--- a/libstdc++-v3/i
The kernel doesn't care what we store in those 32 bits, only that they are
comparable. This commit adds:
* pointers and long on 32-bit architectures
* unsigned
* untyped enums and typed enums on int & unsigned int
* float
We're not using FUTEX_OP anywhere today. The kernel reserves 4 bits for
That violates "don't pay for what you don't need" rule of C++. Users of
std::atomic::wait will often have some bit in their atomic indicate
whether the value is contended or not, so we don't need libstdc++ to do
double book-keeping for us.
---
libstdc++-v3/include/bits/atomic_wait.h | 22 +
On Fri, 2021-02-26 at 10:24 +0100, Andreas Schwab wrote:
> I'm getting this link failure for all compilers:
>
> analyzer/diagnostic-manager.o: In function
> `ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
> const&)':
> diagnostic-manager.cc:(.text+0xd350): undefined reference
ints can be used in futexes. chars can't.
---
libstdc++-v3/include/std/barrier | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index e09212dfcb9..ae058bd3dc3 100644
--- a/libstdc++-v3/inc
Our thread's ID does not change so we don't have to get it every time
and hash it every time.
---
libstdc++-v3/include/std/barrier | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index ae058bd3dc3..e
This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
tests. Tested on x86_64-linux-gnu, and on the affected platform. Ok to
install?
From: Eric Botcazou
for gcc/testsuite/ChangeLog
* lib/target-supports.exp (add_options_for_sqrt_insn): For
PowerPC targets, add -
These tests use -mvsx in their dg-options list, so they are only
applicable if the -mvsx option is supported by the compiler.
Tested with target ppc64-vx7r2, configured to force altivec disabled,
and thus to reject vsx. Ok to install?
From: Joel Brobecker
gcc/testsuite/ChangeLog:
*
On Thu, Feb 25, 2021 at 09:40:58PM -0600, Peter Bergner wrote:
> On 2/25/21 7:09 PM, Segher Boessenkool wrote:
> > On Thu, Feb 25, 2021 at 07:05:26PM -0600, Peter Bergner wrote:
> >> The compat builtin patch was approved for backporting to GCC10, so we'll
> >> need this fix to go along with it.
> >
On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva wrote:
>
> This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
> tests. Tested on x86_64-linux-gnu, and on the affected platform. Ok to
> install?
I'm sort of surprised that sqrt instruction would be available for the
target but no
On Fri, Feb 26, 2021 at 11:14 AM Alexandre Oliva wrote:
>
> These tests use -mvsx in their dg-options list, so they are only
> applicable if the -mvsx option is supported by the compiler.
>
> Tested with target ppc64-vx7r2, configured to force altivec disabled,
> and thus to reject vsx. Ok to ins
On Feb 26 2021, Thiago Macieira via Gcc-patches wrote:
> @@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> }
>
>private:
> -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a;
> +alignas(__alignof__(int)) int _M_a;
Futexes must be aligned to 4 bytes.
Andreas.
--
Andreas Schwa
On Feb 26 2021, David Malcolm wrote:
> What compiler are you using?
gcc 5.3.1
> Does the following patch fix the build for you?
Yes, it does.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something comp
On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote:
> > @@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > }
> >
> > private:
> > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a;
> > +alignas(__alignof__(int)) int _M_a
On Feb 26 2021, Thiago Macieira wrote:
> On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
>> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote:
>> > @@ -85,7 +85,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> > }
>> >
>> > private:
>> > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _
On Fri, 26 Feb 2021, Michael Meissner via Gcc-patches wrote:
> Joseph, does this patch fix your problem?
Yes, this fixes the build without libc done by build-many-glibcs.py.
--
Joseph S. Myers
jos...@codesourcery.com
Hi Kito.
I fixed almost all of the rv32be testcase failures simply by taking
endianness into account on the first line of riscv_subword, which is
used for long long handling on 32-bit.
Now, I only have one failing testcase (which does not also fail on
little endian), and it's a doozy.
The test
Hi
This address one of the more long-standing and serious regressions
for Darwin. GCC emits unwind code by default on the assumption that
the unwinder will be (or have the same capability) as the one in the
current libgcc_s. For Darwin platforms, this is not the case - some
of them are based on
Hi,
The coroutine body is wrapped in a try-catch block which is responsible for
handling any exceptions thrown by the original function body. Originally, the
initial suspend expression was outside this, but an amendment to the standard
places the await_resume call inside and everything else outsi
Hi.
We were discussing proposed reflection splicing syntax - [:reflection:] in SG7
which has some similarities with objective-c++ message syntax with unnamed
params.
This reminded me that we have a *very* long-standing regression against
objective-c++ where it is not able to handle unnamed messag
Jason Merrill wrote:
On 2/24/21 3:06 PM, Iain Sandoe wrote:
The FE contains a mechanism for cleaning up return expressions if a
function throws during the execution of cleanups prior to the return.
If the original function has a return value with a non-trivial DTOR
and the body contains a va
On Fri, 2021-02-26 at 19:33 +0100, Andreas Schwab wrote:
> On Feb 26 2021, David Malcolm wrote:
>
> > What compiler are you using?
>
> gcc 5.3.1
>
> > Does the following patch fix the build for you?
>
> Yes, it does.
Thanks. I've pushed the patch to trunk.
Sorry again for the breakage.
Dave
On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote:
> Just noticed that you didn’t add -fauto-var-init-approach=D to the command
> line.
Ah-ha! I didn't realize that was needed; thanks. However, now some of the
sources crash in a different way. Here's the reproducer:
$ cat poc.i
struct a
Thanks. I will take a look and fix this issue.
BTW, could you please also re-test -ftrivial-auto-var-init=zero
-fauto-var-init-approach=D too?
And let me know are there new issues for -ftrivial-auto-var-init=zero?
(FYI, I have tested -ftrivial-auto-var-init=zero -fauto-var-init-approach=D and
a
On Fri, Feb 26, 2021 at 01:33:41AM -0500, Michael Meissner wrote:
> Honor --disable-decimal-float in building _Float128 support.
>
> Joseph Myers reported that my previous patch to add conversions between
> _Float128 and the Decimal types was still being built even if GCC was
> configured with the
On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> On Feb 26 2021, Thiago Macieira wrote:
> > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> >> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote:
> >> > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a;
> >> > +
On Fri, Feb 26, 2021 at 04:36:20PM -0600, Segher Boessenkool wrote:
> On Fri, Feb 26, 2021 at 01:33:41AM -0500, Michael Meissner wrote:
> > Honor --disable-decimal-float in building _Float128 support.
> >
> > Joseph Myers reported that my previous patch to add conversions between
> > _Float128 and
On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva wrote:
> >
> > This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
> > tests. Tested on x86_64-linux-gnu, and on the affected platform. Ok to
> > install?
>
> I'm so
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-11.1-b20210207.de.po',
On Fri, Feb 26, 2021 at 07:32:25PM -0500, Michael Meissner wrote:
> On Fri, Feb 26, 2021 at 04:36:20PM -0600, Segher Boessenkool wrote:
> > On Fri, Feb 26, 2021 at 01:33:41AM -0500, Michael Meissner wrote:
> > > In addition, I removed the dependency on the target having a valid
> > > stdio.h file
44 matches
Mail list logo
