On Tue, Apr 5, 2022 at 8:06 AM Arnaud Charlet via Gcc-patches
wrote:
>
> > Thank you for the feedback. Should I remove it and resuply the patch or
> > can you/GCC maintainers do the modification before merging?
>
> Can you please resubmit it?
>
> I'll let others comment on the need to sign a contr
On Tue, Apr 5, 2022 at 6:12 AM Sandra Loosemore wrote:
>
> On 3/25/22 20:03, Sandra Loosemore wrote:
> > I've got another patch forthcoming (stage 1 material) that adds some new
> > diagnostics for non-rectangular loops during gimplification of OMP
> > nodes. When I was working on that, I discove
> Thank you for the feedback. Should I remove it and resuply the patch or
> can you/GCC maintainers do the modification before merging?
Can you please resubmit it?
I'll let others comment on the need to sign a contributor agreement, my
understanding is that this is unavoidable, whether you're con
On 4/4/22 13:52, Robin Dapp wrote:
> Hi,
>
> some tests expect a convert instruction but nowadays the conversion is
> already done at compile time. This results in a literal-pool load.
> Change the tests accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
>
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> we have been emitting the "higher" variantes instead of the "not less or
> equal" ones for a while. Change the test expectations accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/ifcvt-two-
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
> s390 the test's while loop is converted into a rawmemchr builtin making
> it impossible to determine that the pointers *p and *q are related.
>
> Therefore, disable the tree loop di
On Mar 31, 2022, Alexandre Oliva wrote:
> g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
> that use the AAPCS variant. ARM is the only target that overrides
> TARGET_CXX_KEY_METHOD_MAY_BE_INLINE. It's not clear to me which way the
> clash between AAPCS and C++ Modules de
On Apr 4, 2022, Richard Sandiford wrote:
> But if that's true, it should happen in gen_rtx_REG.
Yeah, I agree, that makes sense.
> OK without the introduction of the ?:, thanks.
Thanks, here's what I'm checking in.
try multi-reg dest in default_zero_call_used_regs
From: Alexandre Oliva
W
On 3/25/22 20:03, Sandra Loosemore wrote:
I've got another patch forthcoming (stage 1 material) that adds some new
diagnostics for non-rectangular loops during gimplification of OMP
nodes. When I was working on that, I discovered that the Fortran front
end wasn't attaching location information
On 3/25/22 20:02, Sandra Loosemore wrote:
I ran into this bug in the handling of clauses on the combined "masked
taskloop" OMP directive when I was working on something else. The fix
turned out to be a 1-liner. OK for trunk?
Ping! This one's borderline obvious and would be good to fix in GC
On 4/4/22 12:09 PM, Harald Anlauf via Fortran wrote:
Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and cons
On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote:
Dear all,
Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic. The standard allows such recursive references
(see e.g. F2018:19.3.1).
The attac
On Apr 4, 2022, at 4:52 AM, Robin Dapp via Gcc-patches
wrote:
> OK for trunk?
> +/* Since r12-4475-g247c407c83f001 the following immediates are being
> + converted and directly stored in the literal pool so no explicit
> + conversion is necessary. */
Not fan of git revision numbers in the
On 4/1/22 12:42 PM, David Faust wrote:
Hello,
This patch series is a first attempt at adding support for:
- Two new C-language-level attributes that allow to associate (to "tag")
particular declarations and types with arbitrary strings. As explained below,
this is intended to be used t
Am Mon, 04 Apr 2022 23:51:24 +0200
schrieb "Eric Botcazou" :
> Thanks for your contribution. Small nit:
>
> + Support for 128bit integers has beed added.
>
> The support was already present in GCC 11, the criterion being the
> use of the 'Max_Integer_Size attribute in system.ads.
>
> --
> Eric B
> this is my first patch to GCC, if there is anything off, please, say
> so. I have used the default HTML formatting that comes with Emacs. I
> have created the patch using the `git format-patch` utility.
Thanks for your contribution. Small nit:
+ Support for 128bit integers has beed added.
Th
Hi,
this is my first patch to GCC, if there is anything off, please, say
so. I have used the default HTML formatting that comes with Emacs. I
have created the patch using the `git format-patch` utility.
One thing that may not be allowed (I am not aware of any rule against
it but still) is the amo
Ping patch.
| Date: Tue, 29 Mar 2022 23:25:31 -0400
| From: Michael Meissner
| Subject: [PATCH, V2] Optimize vec_splats of constant vec_extract for
V2DI/V2DF, PR target 99293.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Mon, 4 Apr 2022, Martin Liška wrote:
> Ignore:
>
> Checking 86d8e0c0652ef5236a460b75c25e4f7093cc0651: FAILED
> ERR: line should start with a tab: "This reverts commits r12-7804 and
> r12-7929."
> ERR: could not deduce ChangeLog file
>
> It seems Jason pushed the revision to origin/trunk where
Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and conservative solution.
Regtested on x86_64-pc-linux-gnu.
Dear all,
Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic. The standard allows such recursive references
(see e.g. F2018:19.3.1).
The attached patch is based on Steve's, but handles both functio
Hi,
This patch fixes some spelling and grammar issues in the match.pd
documentation.
Pushed as obvious.
Thanks,
Alex
gcc/ChangeLog:
* doc/match-and-simplify.texi: Fix typos.
diff --git a/gcc/doc/match-and-simplify.texi b/gcc/doc/match-and-simplify.texi
index 055a5308e7d..b33d83518a7 10
I'm not sure if it is valid to assume that a linker script "usually" specifies
a fixed memory location.
paul
> On Apr 4, 2022, at 11:06 AM, Carlos Bilbao via Gcc-patches
> wrote:
>
> Projects that rely on a linker script usually specify a memory location
> where the executable sho
Projects that rely on a linker script usually specify a memory location
where the executable should be placed. This directly contradicts the
default option -fpie for position independent executables. In fact, using
PIE generates a GOT, which might be undesirable for developers that need
control o
Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we
need to copy it from newdecl when we merge the declarations.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101894
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Copy DECL_FRIEND_CONTEXT.
gcc/tes
The suggested resolution for CWG1286, which we implemented, ignores default
template arguments, but this PR is an example of why that doesn't make
sense: the templates aren't functionally equivalent.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103852
DR 1286
gcc/cp/Chan
On Mon, Apr 4, 2022 at 1:52 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
> s390 the test's while loop is converted into a rawmemchr builtin making
> it impossible to determine that the pointers *p and *q are related.
>
> Ther
Status
==
The GCC development branch is in regression and documentation fixing
mode (Stage 4) in preparation for the release of GCC 13. Re-opening
of general development will happen once we reach zero P1 regressions
which is when we branch for the release. Time wise history projects
that t
Alexandre Oliva writes:
> Hello, Richard,
>
> Thanks for the review!
>
> On Mar 31, 2022, Richard Sandiford wrote:
>
>>> + /* If the natural mode doesn't work, try some wider mode. */
>>> + if (!targetm.hard_regno_mode_ok (regno, mode))
>>> + {
>>> + for (int nregs = 2;
>>> +
On 04/04/2022 13:12, Jakub Jelinek via Gcc-patches wrote:
On Mon, Apr 04, 2022 at 12:32:27PM +0100, Richard Earnshaw via Gcc-patches
wrote:
OK.
Thanks, now committed.
I think we have a similar issue for arm with arm-tune.md and arm-tables.opt.
Perhaps we should adopt a similar approach f
On Mon, Apr 04, 2022 at 12:32:27PM +0100, Richard Earnshaw via Gcc-patches
wrote:
> OK.
Thanks, now committed.
> I think we have a similar issue for arm with arm-tune.md and arm-tables.opt.
> Perhaps we should adopt a similar approach for those as well.
>From what I can see, both arm and c6x su
Hi,
some tests expect a convert instruction but nowadays the conversion is
already done at compile time. This results in a literal-pool load.
Change the tests accordingly.
OK for trunk?
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/s390/zvector/vec-double-compile.c: Expect vl
Hi,
we have been emitting the "higher" variantes instead of the "not less or
equal" ones for a while. Change the test expectations accordingly.
OK for trunk?
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-two-insns-bool.c: Change nle to h.
* gcc.target/s390/if
Hi,
in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
s390 the test's while loop is converted into a rawmemchr builtin making
it impossible to determine that the pointers *p and *q are related.
Therefore, disable the tree loop distribute patterns pass on s390 for
this test.
OK
On Fri, Apr 1, 2022 at 4:32 PM liuhongt via Gcc-patches
wrote:
>
> Update in V3:
> 1. Add -param=x86-stlf-window-ninsns= (default 64).
> 2. Exclude call in the window.
>
> Since cfg is freed before machine_reorg, just do a rough calculation
> of the window according to the layout.
> Also according
On Mon, 4 Apr 2022 at 11:54, Philipp Fent via Libstdc++
wrote:
>
> This improves the debug output for C++20 spans.
> Before:
> {static extent = 18446744073709551615, _M_ptr = 0x7fffb9a8,
> _M_extent = {_M_extent_value = 2}}
> Now with StdSpanPrinter:
> std::span of length 2 = {1, 2}
Nice, tha
On 4/4/22 13:07, Jakub Jelinek wrote:
On Mon, Apr 04, 2022 at 01:05:12PM +0200, Tom de Vries wrote:
2022-04-04 Tom de Vries
* testsuite/libgomp.fortran/examples-4/on_device_arch.c: Copy from
parent dir.
Wouldn't just ! { dg-additional-sources ../on_device_arch.c }
work?
I
On 04/04/2022 11:49, Jakub Jelinek via Gcc-patches wrote:
On Mon, Apr 04, 2022 at 11:10:14AM +0100, Richard Sandiford wrote:
Normally updates to the source directory files are guarded with
--enable-maintainer-mode, e.g. we don't regenerate configure, config.h,
Makefile.in in directories that
On Mon, Apr 04, 2022 at 01:05:12PM +0200, Tom de Vries wrote:
> 2022-04-04 Tom de Vries
>
> * testsuite/libgomp.fortran/examples-4/on_device_arch.c: Copy from
> parent dir.
Wouldn't just ! { dg-additional-sources ../on_device_arch.c }
work?
Jakub
On 4/1/22 17:57, Tom de Vries wrote:
On 4/1/22 17:38, Jakub Jelinek wrote:
On Fri, Apr 01, 2022 at 05:34:50PM +0200, Tom de Vries wrote:
Do you perhaps have an idea why it's failing?
Because you call on_device_arch_nvptx () outside of
!$omp target region, so unless the host device is NVPTX,
i
This improves the debug output for C++20 spans.
Before:
{static extent = 18446744073709551615, _M_ptr = 0x7fffb9a8,
_M_extent = {_M_extent_value = 2}}
Now with StdSpanPrinter:
std::span of length 2 = {1, 2}
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 38 +++
.../libstdc
On Mon, Apr 04, 2022 at 11:10:14AM +0100, Richard Sandiford wrote:
> > Normally updates to the source directory files are guarded with
> > --enable-maintainer-mode, e.g. we don't regenerate configure, config.h,
> > Makefile.in in directories that use automake etc. unless gcc is configured
> > that
Jakub Jelinek writes:
> Hi!
>
> Normally updates to the source directory files are guarded with
> --enable-maintainer-mode, e.g. we don't regenerate configure, config.h,
> Makefile.in in directories that use automake etc. unless gcc is configured
> that way. Otherwise the source tree can't be e.g
Jakub Jelinek writes:
> Hi!
>
> As I wrote in the PR, our Fedora trunk gcc builds likely after r12-7842
> change are now failing (lto1 crashes).
> What happens is that when one bootstraps into an empty build directory
> (or set of them), mddeps.mk doesn't exist yet and so Makefile doesn't
> includ
The following adds missing verification that the input vectors
have the same number of elements for vectorizable_operation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-04 Richard Biener
PR tree-optimization/105132
* tree-vect-stmts.cc (vectorizable_ope
fold_convertible_p expects an operand and a type to convert to
but recurses with two vector component types. Fixed by allowing
types instead of an operand as well.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-04 Richard Biener
PR middle-end/105140
* fo
Hello Segher,
On 15/03/2022 23:29, Segher Boessenkool wrote:
On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
now that the PR104829 is fixed could I back port
Segher Boessenkool (2):
rs6000: Improve .machine
rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR1048
Hi,
This test makes use of the `__vector(int[4])' type, which is not
supported on all targets, so guard the test with target avx_runtime ||
vect_sizes_16B_8B, fixing PR104740.
Regression tested on x86_64-linux-gnu, committed to mainline.
Regards,
Iain.
---
PR d/104740
gcc/testsuite/Ch
Hi!
Normally updates to the source directory files are guarded with
--enable-maintainer-mode, e.g. we don't regenerate configure, config.h,
Makefile.in in directories that use automake etc. unless gcc is configured
that way. Otherwise the source tree can't be e.g. stored on a read-only
filesystem
Hi!
As I wrote in the PR, our Fedora trunk gcc builds likely after r12-7842
change are now failing (lto1 crashes).
What happens is that when one bootstraps into an empty build directory
(or set of them), mddeps.mk doesn't exist yet and so Makefile doesn't
include it. When building from an empty d
Hello Jørgen,
having support for MC/DC coverage in GCC would be really nice. I tried
out your latest patch on an arm cross-compiler with Newlib (inhibit_libc
is defined). Could you please add the following fix to your patch:
diff --git a/libgcc/libgcov-merge.c b/libgcc/libgcov-merge.c
index 8
Ignore:
Checking 86d8e0c0652ef5236a460b75c25e4f7093cc0651: FAILED
ERR: line should start with a tab: "This reverts commits r12-7804 and r12-7929."
ERR: could not deduce ChangeLog file
It seems Jason pushed the revision to origin/trunk where the checking script is
not run.
@Jakub: Can you pleas
After r12-7931 we again honor MOVE_MAX when folding memcpy to
a load/store pair. On i?86-*-* without SSE this now exposes the
change done in r12-2666-g29f0e955c97da0 which adjusts MOVE_MAX
from 16 to 4 on those targets. This makes adjusting testcases
necessary that assume that we transform memcpy
53 matches
Mail list logo
