Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 6/11/2020 上午 9:02, HAO CHEN GUI wrote:
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 15/10/2020 下午 4:46, HAO
Simplify
((b | c) & a) | b
to
(a & c) | b.
This fixes PR96679.
Tested on x86_64-pc-linux-gnu.
int f(int a, int b, int c)
{
return ((b | c) & a) | b;
}
Code without the patch:
or edx,esi
andedx,edi
moveax,edx
or eax,esi
ret
Code with the patch:
andedi,edx
moveax,edi
On Fri, 20 Nov 2020, Matthew Malcomson wrote:
>>> The patch is okay modulo the question above.
> Apologies for bringing up something from this far back, but I've just
> noticed I never actually committed this patch.
Actually thank you for doing so! (And I am known to sometimes bring
up things qu
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
...and there are multiple definition complaints from the linker because
of two missing "include":
index 7b2682a577e..23ab2018ca8 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/
Generate special double mode sequence also for TImode on 64bit targets.
2020-11-22 Uroš Bizjak
PR target/97873
gcc/
* config/i386/i386.md (abs2): Use SWI48DWI mode iterator.
(*abs2_doubleword): Use DWIH mode iterator.
(3): Use SWI48DWI mode iterator.
(*3_doubleword): Use
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
Clang complains:
$ cat test.cc
#include
$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc
In file included from test.cc:1:
In file included from
~/gcc/trunk/inst/lib/gcc/x86_64-pc-li
Hi,
When appending a character to an array, the result of that concat
assignment was not the new value of the array, similarly, when appending
an array to another array, side effects were evaluated in reverse to the
expected order of evaluation.
As of this change, the address of the left-hand sid
Hi Ian,
> This patch to the Go frontend and libgo changes the name mangling
> convention. The previous convention (which was actually the second
> one) turned out to be ambiguous when the path to a package contained a
> dot; this is a common case, as many package paths are of the form
> "github.c
Partially revert recent H8 patch for conditional branches
So I'd forgotten an important tidbit on the H8 port. Specifically
for a branch instruction, the target label must be operand 0 for
the length computations.
This really only affects the main conditional branch pat
On 2020-11-21 12:27, J.W. Jagersma wrote:
> ...
> Another idea I had is to introduce a new operand modifier, eg. '-', which
> would signify that the output *must* be considered clobbered on exception,
> and it would be an error if a copy is not possible. Then the meaning of '+'
> can be extended t
Hi
We have a similar code pattern in darwin-c.c to one in c-pragmas
(most likely a cut & paste) with a struct type used locally to the
TU. With C++ we need to rename the type to avoid an ODR violation.
tested on x86_64-darwin19 ‘—with-build-config=bootstrap-lto-noplugin’
pushed to master,
thank
On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote:
> thanks for looking at this over the weekend.
>
> Jonathan Wakely via Gcc-patches wrote:
>
> > On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
> > wrote:
> >> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
> >> fixe
thanks for looking at this over the weekend.
Jonathan Wakely via Gcc-patches wrote:
On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
wrote:
I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes. And a few c++ failures with similar symptoms. I'm not certain
tha
On Sun, Nov 15, 2020 at 12:08:22PM -0500, Vladimir Makarov via Gcc-patches
wrote:
> --- a/gcc/lra.c
> +++ b/gcc/lra.c
> @@ -1903,15 +1903,23 @@ lra_process_new_insns (rtx_insn *insn, rtx_insn
> *before, rtx_insn *after,
> {
> /* We already made the edge no-critical in ir
Hi,
this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
just lead to silent code failure of the worst kind
(non-reproducable, racy) at runtime, as was pointed out
on previous discussions he
15 matches
Mail list logo
