Hi!
Here is an attempt to resolve a P1 regression, where due to threading
changes we no longer optimize
bool foo(int i) {
while (i == 4)
i += 2;
return i;
}
to just return i != 0; by enhancing the phiopt value_replacement
optimization. Normally it will optimize x != cst1 ? x : cst
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loo
在 2022/4/9 上午5:48, Xi Ruoyao 写道:
Another simple testcase change for LoongArch. Ok for trunk?
---
LoongArch backend allocates two additional 8-byte stack slots for LP64,
one for saving $fp and another for saving the temporary value "1".
Ideally they are both unneeded, but (1) we're using -O0
在 2022/4/9 上午5:46, Xi Ruoyao 写道:
A simple testcase change, tested on loongarch64-linux-gnuabif64. Ok for trunk?
---
On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should
On 4/7/22 18:25, Alexandre Oliva wrote:
Hello, Jason,
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted
as part of the git transition:
https://gcc.gnu.org/contribute.html#patches
Oh, wow, I
On 4/7/22 18:48, Alexandre Oliva wrote:
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
*nod*, thanks
* tree.cc (protected_set_expr_location): Propagate locus to
call wrapped in cast-to-void.
I'm reluctant to put t
My patch for PR92385 made us use VEC_INIT_EXPR for aggregate initialization
of an array where some elements are not explicitly initialized. Constexpr
handling of that was treating initialization from {} as equivalent to
value-initialization, which is problematic for classes with default member
ini
This rule that for a friend with a qualified name we try to find a
matching template was already in C++98, but it seems we never implemented
it, and nobody reported it until 2019.
This patch sets DECL_IMPLICIT_INSTANTIATION to signal to
check_explicit_specialization that we want to find a template
Another simple testcase change for LoongArch. Ok for trunk?
---
LoongArch backend allocates two additional 8-byte stack slots for LP64,
one for saving $fp and another for saving the temporary value "1".
Ideally they are both unneeded, but (1) we're using -O0 so the code is
suboptimized by the na
A simple testcase change, tested on loongarch64-linux-gnuabif64. Ok for trunk?
---
On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should be skipped.
[1]:
https://loongson.
On Wed, Apr 06, 2022 at 03:01:33PM -0500, will schmidt wrote:
> In this context it's not clear what is the "old code" ?
> The mtvsrdd
> instruction is referenced in this code path. I see no direct reference
> to lxvrdx here, though I suppose it's assumed somewhere behind the
> emit_ calls.
The lx
Dear all,
Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran:
Dear all,
the logic for checking the allocate-coshape-spec in an ALLOCATE
statement was sort of sideways, and allowed to pass invalid
specifications to the code generation.
The fix seems obvious (to me).
after submitting the p
On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:
> I'm excited to read that rustc_codegen_gcc, the libgccjit-based
> backend
> for rustc can now bootstrap rustc:
> https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10
>
> I've been focusing on the analyzer, and so haven't been as o
David, it seems you missed this email that contains the updated patch
and a few questions.
Attaching the patch again.
Thanks for the reviews!
On Fri, 2022-01-21 at 11:22 -0500, Antoni Boucher via Jit wrote:
> David: this is the email I was talking about in my other email.
> Here's the updated pa
On Apr 08 2022, Patrick O'Neill wrote:
> It looks like the file:
> gcc/config/nds32/linux.h
> interacts with the macro:
> #define HAVE_sync_compare_and_swaphi 1
>
> I'm not sure if that's the correct way to do it/if this is defined in a
> different way for targets like x86/ARM/etc.
They are norma
Hi!
On Mon, Feb 28, 2022 at 11:17:27AM +0800, HAO CHEN GUI wrote:
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to be
> backpo
I'm excited to read that rustc_codegen_gcc, the libgccjit-based backend
for rustc can now bootstrap rustc:
https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10
I've been focusing on the analyzer, and so haven't been as on top of
libgccjit patch review as I should have been. Sorry about
On Fri, 2022-01-21 at 18:41 -0500, Antoni Boucher wrote:
> Hi.
> Here's the updated patch.
>
Thanks. Review below:
[...snip...]
> diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> index 4c352e8c93d..6bf1e1ceee0 100644
> --- a/gcc/jit/libgccjit.cc
> +++ b/gcc/jit/libgccjit.cc
> @@ -240
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
> On 4/1/22 15:14, Marek Polacek wrote:
> > Attribute format takes three arguments: archetype, string-index, and
> > first-to-check. The last two specify the position in the function
> > parameter list. r63030 clarified that "Since no
On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches
wrote:
> Hi.
> This patch adds support for setting the alignment of variables in
> libgccjit.
Thanks. Sorry about the delay in reviewing it.
>
> I was wondering if I should change it so that it takes/returns bytes
> instead of bi
Hi Pan RZ,
I appreciate the help - that's a good starting point for the macros.
It looks like the file:
gcc/config/nds32/linux.h
interacts with the macro:
#define HAVE_sync_compare_and_swaphi 1
I'm not sure if that's the correct way to do it/if this is defined in a
different way for targets lik
Hi Patrick,
We are more than delighted to hear that you'd like to implement inlining
subword atomic load/store and exchange as well!
I searched for these macros in the gcc codebase, and it seems like the
internal logic that defines ATOMIC_* builtin macros can be found at
gcc/c-family/c-cpp
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105153
* include/std/expected
(expected::expected(expected&&)): Fix constraints.
* testsuite/20_util/expected/cons.cc: Check constructor.
---
libstdc++-v3/include/std/expected
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105154
* include/std/expected (expected::swap): Set
_M_has_value to false for objects that previously had a value.
* testsuite/20_util/expected/swap.cc: Fix test to check void
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105146
* include/std/expected (bad_expected_access): Move constructor
parameter.
* testsuite/20_util/expected/bad.cc: New test.
---
libstdc++-v3/include/std/expected
On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
> As Jakub noted here, we don't have the soft-float support for both m32 and m64
> before, as the bifs are always guarded under hard-float previously.
But that bug was fixed for GCC 12. Or we thought so, at least :-(
> >> What makes it I
On Thu, Apr 07, 2022 at 03:00:14PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote:
> > > As PR103623 shows, it's a regression failure due to new built-in
> > > function framework, previo
Hi RZ Pan,
I'll start working on the atomic store/exchange stuff. It shouldn't be
too difficult to add since it will have similar masking logic to
atomic fetch.
Also - I briefly looked and couldn't find the place where those macro's
values for RISC-V are defined in GCC. If anyone can point me in
On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to b
Add
AC_CONFIG_MACRO_DIRS([../config])
So that just running:
$ autoreconf -vf
... does the right thing (no need to specify -I ../config).
Note: I don't have access to the gcc repo, so if this patch is approved,
can somebody push it there on my behalf? I can push it to binutils-gdb.
libibe
On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote:
> As PR103623 shows, it's a regression failure due to new built-in
> function framework, previously we guard __builtin_{un,}pack_{longdouble,
> ibm128} built-in functions under hard float, so they are unavailable
> with the given configurat
On 2022-04-08 10:32, Nick Clifton wrote:
> Hi Simon,
>
>> Ping.
>
> Patch approved - please apply.
>
> I appreciate that modifying these top level files is a bit nerve
> wracking, but I think that you have done a good job in this case. :-)
>
> Cheers
> Nick
>
Thanks Nick, pushed.
Simon
Hi,
This patch is removing unnecessary armv9-a multilib variant which was
introduced in commit 32ba7860ccaddd5219e6dae94a3d0653e124c9dd (add
armv9-a architecture to -march). Now armv9-a(+simd) multilibs point to
already existing armv8-a(+simd) ones as there are no changes between
the two.
Users wi
Hi!
Thanks for investigating.
On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote:
> on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
> > On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
> >> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
> >>> As PR103196 sh
Hi Simon,
Ping.
Patch approved - please apply.
I appreciate that modifying these top level files is a bit nerve
wracking, but I think that you have done a good job in this case. :-)
Cheers
Nick
When predictive commoning looks for a looparound PHI it tries
to match the entry value definition (a load) up with the appropriate
member of the chain. But it fails to consider stmts clobbering
the very same memory location inbetween the load and loop entry.
In theory we could be more clever on m
On Fri, Apr 8, 2022 at 12:55 PM Martin Jambor wrote:
>
> Hi,
>
> a scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
> platforms. I investigated only i?86-*-* with -mno-sse but assume the
> issue is the same on all of the affected platform.
>
> Because function bar is not inlined
Hi,
a scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
platforms. I investigated only i?86-*-* with -mno-sse but assume the
issue is the same on all of the affected platform.
Because function bar is not inlined there even though it is only called
once, the process that is being
"Andre Vieira (lists)" writes:
> On 08/04/2022 08:04, Richard Sandiford wrote:
>> I think this would be better as a static assert at the top level:
>>
>>static_assert (TARGET_CPU_generic < TARGET_CPU_MASK,
>> "TARGET_CPU_NBITS is big enough");
> The motivation being that you want
On 08/04/2022 08:04, Richard Sandiford wrote:
I think this would be better as a static assert at the top level:
static_assert (TARGET_CPU_generic < TARGET_CPU_MASK,
"TARGET_CPU_NBITS is big enough");
The motivation being that you want this to be checked regardless of
wheth
On 08/04/2022 09:33, Jørgen Kvalsvik wrote:
On 08/04/2022 09:28, Jørgen Kvalsvik wrote:
On 07/04/2022 18:53, Sebastian Huber wrote:
Hello Jørgen,
there could be an issue with conditions in for loops:
3: 189: for (int a = 0; a <= 1; ++a) {
branch 0 taken 2
branch 1 taken 1 (fallth
on 2022/4/8 4:04 PM, Jakub Jelinek wrote:
> On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote:
>> + /* Let's ignore all error messages about built-in function
>> + unsupported due to soft-float, since they are not test
>> + points here (this case is to check no ICE). */
>> + /* {
On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote:
> + /* Let's ignore all error messages about built-in function
> + unsupported due to soft-float, since they are not test
> + points here (this case is to check no ICE). */
> + /* { dg-error ".*" "pr103623" { target *-*-* } .-19
On Wed, Apr 06, 2022 at 09:26:56PM -0400, Jason Merrill via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.c-torture/compile/20050113-1.c: Moved to...
> * c-c++-common/torture/20050113-1.c: ...here.
The test FAILs on i686-linux if neither MMX isn't enabled, can be also
reprod
Hi Will,
on 2022/4/7 10:19 PM, will schmidt wrote:
> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
...
>> -
>> PR testsuite/103196
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/powerpc/p9-vec-length-7.h: Add DO_PRAGMA macro.
>> * gcc.target/po
On 4/8/22 00:27, Thomas Schwinge wrote:
Hi!
On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
Especially for distributions it is undesirable to need to have proprietary
CUDA libraries and headers installed when building GCC.
--- libgomp/plugin/configfrag.ac.jj 2017-01-13 12:07:56.
On 08/04/2022 09:28, Jørgen Kvalsvik wrote:
> On 07/04/2022 18:53, Sebastian Huber wrote:
>> Hello Jørgen,
>>
>> there could be an issue with conditions in for loops:
>>
>> 3: 189: for (int a = 0; a <= 1; ++a) {
>> branch 0 taken 2
>> branch 1 taken 1 (fallthrough)
>> conditions covered
Hi!
The following testcase ICEs with C++ and is incorrectly rejected with C.
The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD
and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP
directives etc., like:
/* Save away the identifier that indicates w
On 07/04/2022 18:53, Sebastian Huber wrote:
> Hello Jørgen,
>
> there could be an issue with conditions in for loops:
>
> 3: 189: for (int a = 0; a <= 1; ++a) {
> branch 0 taken 2
> branch 1 taken 1 (fallthrough)
> conditions covered 0/2
> condition 0 not covered (true)
> condition
Hi!
on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
>> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
>>> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
>>> complete unrolling can ha
Hi,
As PR103623 shows, it's a regression failure due to new built-in
function framework, previously we guard __builtin_{un,}pack_{longdouble,
ibm128} built-in functions under hard float, so they are unavailable
with the given configuration. While with new bif infrastructure, it
becomes available
"Andre Vieira (lists)" writes:
> Hi,
>
> This addresses the compile-time increase seen in the PR target/105157.
> This was being caused by selecting the wrong core tuning, as when we
> added the latest AArch64 the TARGET_CPU_generic tuning was pushed beyond
> the 0x3f mask we used to encode bot
52 matches
Mail list logo
