On 6/30/2022 8:22 PM, Hongtao Liu via Gcc-patches wrote:
I think this can be taken as an obvious fix without prior approval.
"Obvious fixes can be committed without prior approval. Just check in
the fix and copy it to gcc-patches."
Quoted from https://gcc.gnu.org/gitwrite.html
If we've given
On Fri, Jul 1, 2022 at 10:12 AM Hongtao Liu wrote:
>
> On Fri, Jul 1, 2022 at 2:42 AM Roger Sayle wrote:
> >
> >
> > This patch is a follow-up to Hongtao's fix for PR target/105854. That
> > fix is perfectly correct, but the thing that caught my eye was why is
> > the compiler generating a
I think this can be taken as an obvious fix without prior approval.
"Obvious fixes can be committed without prior approval. Just check in
the fix and copy it to gcc-patches."
Quoted from https://gcc.gnu.org/gitwrite.html
On Fri, Jul 1, 2022 at 10:02 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi
On Fri, Jul 1, 2022 at 2:42 AM Roger Sayle wrote:
>
>
> This patch is a follow-up to Hongtao's fix for PR target/105854. That
> fix is perfectly correct, but the thing that caught my eye was why is
> the compiler generating a shift by zero at all. Digging deeper it
> turns out that we can
Hi all,
I want to add myself in MAINTAINERS for write after approval.
Ok for trunk?
BRs,
Haochen
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 151770f59f4..3c448ba9eb6
/This patch is the initial implementation of OpenMP-API specs book section //20.5.5 with title "Thread Handles". /libgomp/ChangeLog /2022-07-01
Ahmed Sayed // * Makefile.am
(libgompd_la_SOURCES): Add ompd-threads.c.///* Makefile.in: Regenerate. * team.c ( gomp_free_thread ): Called
On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
> +proc check_effective_target_two_plus_gigs { } {
> +return [check_no_compiler_messages two_plus_gigs executable {
> + int dummy[0x8000];
Don't you mean "char" as in "char dummy[0x8000]"?
Or else the effective predicate
The following patches have been committed to devel/omp/gcc-12 to fix a
bootstrap build of the branch:
29ba2e4eeff Fix mis-merge of 'dwarf: Multi-register CFI address support'
82a3f9f22f7 Build fixes for OG12 on more recent GCC versions
e9ee746093b Fix string formatting issues
b8ecb83d528 Build
When optimizing for size with -Oz, setting a register can be minimized by
pushing an immediate value to the stack and popping it to the destination.
Alas the one general register that shouldn't be updated via the stack is
the stack pointer itself, where "pop %esp" can't be represented in GCC's
On Wed, Jun 1, 2022 at 3:21 PM Jason Merrill via Gcc-patches
wrote:
>
> This testcase demonstrates that the issue in PR105623 is not limited to
> templates, so we should do the marking in a less template-specific place.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> PR c++/105779
Hi Tobias,
Am 30.06.22 um 11:58 schrieb Tobias Burnus:
The initial patch is by Steve. I adjusted and moved
it slightly so that it also handles CLASS(*)
(unlimited polymorphic) at the same time.
Shouldn't you then also acknowledge him, e.g. via Co-authored-by?
yeah, I noticed that right
On Thu, Jun 30, 2022 at 9:59 AM Sören Tempel wrote:
>
> Ian Lance Taylor wrote:
> > Thanks for the info. Does this patch work? It tweaks the handling of
> > SYS_SECCOMP to be specific to that constant.
>
> Yes, your patch works for me too on Alpine Linux Edge.
Thanks. Committed to mainline.
> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote:
>
> On Thu, Jun 30, 2022 at 03:31:00PM +, Qing Zhao wrote:
>>> No, that’s not true. A FIELD_DELC is only shared for cv variants of a
>>> structure.
>>
>> Sorry for my dump questions:
>>
>> 1. What do you mean by “cv variants” of a
This patch is a follow-up to Hongtao's fix for PR target/105854. That
fix is perfectly correct, but the thing that caught my eye was why is
the compiler generating a shift by zero at all. Digging deeper it
turns out that we can easily optimize __builtin_ia32_palignr for
alignments of 0 and 64
On Linux/x86_64,
0f6eef398045deb2a62d18b526831719c7c20c8a is the first bad commit
commit 0f6eef398045deb2a62d18b526831719c7c20c8a
Author: Kito Cheng
Date: Tue Jun 28 18:43:42 2022 +0800
testsuite/102690: Only check warning for lp64 in Warray-bounds-16.C
caused
FAIL:
On Thu, Jun 30, 2022 at 03:21:15PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > +/* The initial ICV values for the host, which are configured with
> > > environment
> > > + variables without a suffix, e.g.
On Thu, Jun 30, 2022 at 03:31:00PM +, Qing Zhao wrote:
> > No, that’s not true. A FIELD_DELC is only shared for cv variants of a
> > structure.
>
> Sorry for my dump questions:
>
> 1. What do you mean by “cv variants” of a structure?
const/volatile qualified variants. So
> 2. For the
Ian Lance Taylor wrote:
> Thanks for the info. Does this patch work? It tweaks the handling of
> SYS_SECCOMP to be specific to that constant.
Yes, your patch works for me too on Alpine Linux Edge.
Thanks!
Greetings,
Sören
Tested powerpc64le-linux, OK for trunk?
-- >8 --
Since C++11 relaxed the requirement for template arguments to have
external linkage, it's possible to get -Wsubobject-linkage warnings
without using any anonymous namespaces. This confuses users when they
get diagnostics that refer to an anonymous
No testcase for this, since I haven't found a way to turn the incorrect
attribute into incorrect codegen.
Bootstrapped and tested on aarch64-none-linux gnu.
gcc/
* config/aarch64/aarch64-builtins.c
(aarch64_get_attributes): Fix choice of pure/const attributes.
---
diff --git
> On Jun 30, 2022, at 10:24 AM, Richard Biener
> wrote:
>
>
>
>> Am 30.06.2022 um 16:08 schrieb Qing Zhao via Gcc-patches
>> :
>>
>>
>>
>>> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>>>
>>> On 6/28/22 13:01, Qing Zhao wrote:
> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/utility.h: Fix comment typos.
---
libstdc++-v3/include/bits/utility.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/utility.h
On Thu, Jun 30, 2022 at 04:11:42PM +0100, Jonathan Wakely via Gcc-patches wrote:
> I recently changed to no longer include an unnecessary header,
> which meant it no longer includes , which means it no longer
> includes . This resulted in some build failures:
>
I recently changed to no longer include an unnecessary header,
which meant it no longer includes , which means it no longer
includes . This resulted in some build failures:
https://issues.apache.org/jira/browse/LUCENE-10630
https://github.com/openSUSE/libzypp/pull/405
And that revealed that we
1. Add a predicate for constant vectors which can be converted to integer
constants suitable for constant integer stores. For a 8-byte constant
vector, the converted 64-bit integer must be valid for store with 64-bit
immediate, which is a 64-bit integer sign-extended from a 32-bit integer.
2. Add
Properly allow side effects only for a first BB in a condition chain.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR tree-optimization/106126
gcc/ChangeLog:
* gimple-if-to-switch.cc (struct condition_info): Save
> Am 30.06.2022 um 16:08 schrieb Qing Zhao via Gcc-patches
> :
>
>
>
>> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>>
>> On 6/28/22 13:01, Qing Zhao wrote:
On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>
> On 6/28/22 13:01, Qing Zhao wrote:
>>> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote:
>
>
On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > +/* The initial ICV values for the host, which are configured with
> > environment
> > + variables without a suffix, e.g. OMP_NUM_TEAMS. */
> > +struct gomp_initial_icvs gomp_initial_icvs_none;
> > +
> > +/*
> We can go with a private vect_gimple_build function until we sort out the API
> issue to unblock Tamar (I'll reply to Richards reply with further thoughts on
> this)
>
Done.
> > Similarly are you ok with the use of gimple_extract_op? I would lean
> towards using it as it is cleaner, but I
Tested x86_64-linux and x86_64-mingw, pushed to trunk.
-- >8 --
Currently the throwing overload of fs::temp_directory_path() will
discard the path that was obtained from the environment. When it fails
because the path doesn't resolve to a directory you get an unhelpful
error like:
filesystem
Tested x86_64-linux and x86_64-mingw, pushed to trunk.
-- >8 --
Although the Filesystem TS isn't properly supported on Windows (unlike
the C++17 Filesystem lib), most tests do pass. Two of the failures are
due to PR 1 which was only fixed for std::filesystem not the TS.
This applies the fix
On Thu, Apr 14, 2022 at 06:06:24PM +0200, Marcel Vollweiler wrote:
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -13994,7 +13994,7 @@ optimize_target_teams (tree target, gimple_seq *pre_p)
>struct gimplify_omp_ctx *target_ctx = gimplify_omp_ctxp;
>
>if (teams == NULL_TREE)
> -
On Thu, Jun 30, 2022 at 02:30:24PM +0200, Tobias Burnus wrote:
> OK for mainline - or should I put that patch into the bin?
Not sure, the other match* macros also aren't wrappers
around another macro and with the internal macro it means we'll
need to parse more many times (even when we then fold
This patch makes the vrange_allocator an abstract class, and uses it
to implement the obstack allocator as well as a new GC allocator.
The GC bits will be used to implement the vrange storage class for
global ranges, which will be contributed in the next week or so.
Tested and benchmarked on
I initially thought that I need another set of macros - and started with
this cleanup. I then realized that I don't.
However, I still wonder whether this cleanup makes sense even if only
4 macros are affected.
OK for mainline - or should I put that patch into the bin?
Tobias
-
On Thu, Jun 30, 2022 at 12:56 PM Roger Sayle wrote:
>
>
> Hi Uros,
> Many thanks for your review of the "double word logical operation clean-up"
> patch.
> The revision below incorporates the majority of your feedback, but with one
> or two
> exceptions (required to allow the patch to
In order to prune ordinary locations, we need to note the locations of
macros we'll be writing out. This reaaranges the macro processing to
achieve that. Also drop an unneeded parameter from macro reading & writing.
Fix some it's/its errors.
nathan
--
Nathan SidwellFrom
Hi Xi,
> A documentation improvement with no code change. OK for trunk?
>
> -- >8 --
>
> We are receiving several reports that people are (mis)using
> --enable-libsanitizer option, which was not documented by GCC
> installation doc. It forces to build libsanitizer even for unsupported
>
On Fri, Jun 10, 2022 at 03:59:37PM +0200, Marcel Vollweiler wrote:
> > I'm not sure we can rely on execv on all targets that do support libgomp.
> > Any reason why you actually need this, rather than using
> > dg-set-target-env-var directive(s) and perhaps return 0; if getenv doesn't
> > return
As pointed out by Richard, it's very likely too big of a hammer.
Bootstrapped/regtested on x86-64/Linux, OK for the mainline?
2022-06-30 Eric Botcazou
PR middle-end/105874
* expr.cc (expand_expr_real_1) : Force
EXPAND_MEMORY for the expansion of the inner reference
Hi Uros,
Many thanks for your review of the "double word logical operation clean-up"
patch.
The revision below incorporates the majority of your feedback, but with one or
two
exceptions (required to allow the patch to bootstrap) that I thought I'd double
check
with you before pushing.
A documentation improvement with no code change. OK for trunk?
-- >8 --
We are receiving several reports that people are (mis)using
--enable-libsanitizer option, which was not documented by GCC
installation doc. It forces to build libsanitizer even for unsupported
targets, causing build
Dear Harald, dear all,
On 29.06.22 21:54, Harald Anlauf via Fortran wrote:
a CLASS entity cannot have the PARAMETER attribute.
This is detected in some situations, but in others
we ICE because we never reach the existing check.
Adding a similar check when handling the declaration
improves error
Hi Jakub,
On 30.06.22 10:21, Jakub Jelinek wrote:
So, what is the plan with reverse offload?
My idea was to just call omp_target_ext with
'device(omp_initial_device)'. This then automatically
works when called from a target region that runs on
omp_get_initial_device().
For the actual device
> -Original Message-
> From: Uros Bizjak
> Sent: Thursday, June 30, 2022 4:53 PM
> To: Jiang, Haochen
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> Subject: Re: [PATCH] i386: Extend cvtps2pd to memory
>
> On Thu, Jun 30, 2022 at 10:45 AM Uros Bizjak wrote:
> >
> > On Thu, Jun 30,
On Thu, Jun 30, 2022 at 10:45 AM Uros Bizjak wrote:
>
> On Thu, Jun 30, 2022 at 9:41 AM Uros Bizjak wrote:
> >
> > On Thu, Jun 30, 2022 at 9:24 AM Jiang, Haochen
> > wrote:
> > >
> > > > -Original Message-
> > > > From: Uros Bizjak
> > > > Sent: Thursday, June 30, 2022 2:20 PM
> > > >
On Thu, Jun 30, 2022 at 9:41 AM Uros Bizjak wrote:
>
> On Thu, Jun 30, 2022 at 9:24 AM Jiang, Haochen
> wrote:
> >
> > > -Original Message-
> > > From: Uros Bizjak
> > > Sent: Thursday, June 30, 2022 2:20 PM
> > > To: Jiang, Haochen
> > > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> >
Anything dealing with the hybrid threader could probably use a little
clean up. I've neglected to do so, as I'm hoping to nuke the forward
threader altogether and replace it with the backwards threader.
However, in order to do this, we need to implement prange (pointers)
and frange (floats) to
On 6/30/22 08:43, Rui Ueyama wrote:
> Thanks Martin for creating this patch.
You're welcome.
>
> Here is a preliminary change for the mold side:
> https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605
>
>
At some point when domwalk got the ability to use RPO for ordering
dominator children we carefully avoided update_ssa eating the cost
of RPO compute. Unfortunately some later consolidation of CTORs
lost this again so the following makes this explicit via a special
value to the bb_index_to_rpo
Hi.
I'm going to push the following clean-up.
Martin
gcc/ChangeLog:
* tree-ssa-dom.cc (pass_dominator::execute): Remove m_ranger as
it is unused.
---
gcc/tree-ssa-dom.cc | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/gcc/tree-ssa-dom.cc
On Wed, Jun 29, 2022 at 09:54:56PM +0200, Tobias Burnus wrote:
> Currently, this is a rather useless patch - even though it helps to reduce
> the number of local patches I have. Due to the printed sorry, adding a
> testcase with -fdump-tree-* is also not possible, yet.
>
> For reverse offload,
On 30/06/2022 09:52, Alexandre Oliva via Gcc-patches wrote:
On Jun 27, 2022, Alexandre Oliva wrote:
I see two potential ways to avoid this:
Another possibility occurred to me: seeking back to the entry we're
about to remove, before removing it. Then, POSIX-compliant
implementations will
On Jun 27, 2022, Alexandre Oliva wrote:
> I see two potential ways to avoid this:
Another possibility occurred to me: seeking back to the entry we're
about to remove, before removing it. Then, POSIX-compliant
implementations will just skip the removed entry and find the next one,
while RTEMS
On Thu, Jun 30, 2022 at 9:24 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Uros Bizjak
> > Sent: Thursday, June 30, 2022 2:20 PM
> > To: Jiang, Haochen
> > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> > Subject: Re: [PATCH] i386: Extend cvtps2pd to memory
> >
> > On Thu,
> -Original Message-
> From: Uros Bizjak
> Sent: Thursday, June 30, 2022 2:20 PM
> To: Jiang, Haochen
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> Subject: Re: [PATCH] i386: Extend cvtps2pd to memory
>
> On Thu, Jun 30, 2022 at 7:59 AM Haochen Jiang
> wrote:
> >
> > Hi all,
> >
> >
On Thu, Jun 30, 2022 at 5:00 AM Xi Ruoyao via Gcc-patches
wrote:
>
> Hi,
>
> We've made a consensus [1] that not to enable trapping for division by
> zero by default for LLVM, and we think GCC should behave similarly.
>
> The main rationales:
>
> 1. Division by zero is undefined behavior, so in
On Thu, Jun 30, 2022 at 4:17 AM Kito Cheng wrote:
>
> Committed to trunk, thanks :)
>
> Is it OK for gcc-11 and gcc-12 branches?
Yes, if the same failure is corrected there
> On Wed, Jun 29, 2022 at 5:00 PM Richard Biener wrote:
> >
> > On Tue, 28 Jun 2022, Kito Cheng wrote:
> >
> > > That
On Wed, Jun 29, 2022 at 4:35 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jun 28, 2022 at 5:54 PM Tamar Christina
> > wrote:
> >>
> >> > -Original Message-
> >> > From: Richard Biener
> >> > Sent: Monday, June 27, 2022 7:10 AM
> >> > To: Tamar Christina
> >> >
Thanks Martin for creating this patch.
Here is a preliminary change for the mold side:
https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605
Overall the API is looking fine, though it is not clear what kind of value
is expected as a linker version. A linker version is
On Thu, Jun 30, 2022 at 7:59 AM Haochen Jiang wrote:
>
> Hi all,
>
> This patch aims to fix the cvtps2pd insn, which should also work on
> memory operand but currently does not. After this fix, when loop == 2,
> it will eliminate movq instruction.
>
> Regtested on x86_64-pc-linux-gnu. Ok for
62 matches
Mail list logo
