On Tue, 1 Mar 2022, H.J. Lu wrote:
> Use C++ RAII with make_temp_override in the C++ FE to automatically clear
> currently_expanding_gimple_stmt.
Hmm, the temp-override isn't really a good fit since we only want to
have the cleanup part and that should always "restore" to nullptr.
Richard.
>
On Tue, Mar 1, 2022 at 5:23 PM Hongtao Liu wrote:
>
> On Wed, Mar 2, 2022 at 6:49 AM H.J. Lu wrote:
> >
> > On Tue, Mar 1, 2022 at 7:06 AM H.J. Lu wrote:
> > >
> > > On Mon, Feb 28, 2022 at 9:36 PM Hongtao Liu wrote:
> > > >
> > > > On Tue, Mar 1, 2022 at 10:39 AM H.J. Lu via Gcc-patches
> > >
Use standard C type instead of __int64_t which doesn't work on Solaris.
Tested by Rainer Orth on Solaris/x86. Pushed to trunk as obvious fix.
gcc/testsuite/ChangeLog:
PR target/104724
* gcc.target/i386/avx512fp16-vcvtsi2sh-1b.c: Use long long
instead of __int64_t.
On Wed, Mar 2, 2022 at 6:49 AM H.J. Lu wrote:
>
> On Tue, Mar 1, 2022 at 7:06 AM H.J. Lu wrote:
> >
> > On Mon, Feb 28, 2022 at 9:36 PM Hongtao Liu wrote:
> > >
> > > On Tue, Mar 1, 2022 at 10:39 AM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 6:26 PM H.J. Lu
Use avx2-check mechanism to avoid illegal instrucion on non-avx2 target.
Tested by Rainer Orth on Solaris/x86. Pushed to trunk as obvious fix.
gcc/testsuite/ChangeLog:
PR target/104726
* gcc.target/i386/pr104551.c: Use avx2-check.h.
---
gcc/testsuite/gcc.target/i386/pr104551.c
On Tue, Mar 1, 2022 at 12:41 AM HAO CHEN GUI wrote:
>
> Hi,
>This patch enables absolute jump tables on PPC AIX and Linux. For AIX, the
> jump
> table is placed in data section. For Linux, it is placed in RELRO section when
> relocation is needed.
>
>Bootstrapped and tested on AIX,Linux
Pinging the two patches here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590230.html
On 2/10/22 16:04, Martin Sebor wrote:
On 2/8/22 15:37, Jason Merrill wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types
On Tue, Mar 1, 2022 at 7:06 AM H.J. Lu wrote:
>
> On Mon, Feb 28, 2022 at 9:36 PM Hongtao Liu wrote:
> >
> > On Tue, Mar 1, 2022 at 10:39 AM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > On Mon, Feb 28, 2022 at 6:26 PM H.J. Lu wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 6:03 PM liuhongt
Add TARGET_FOLD_MEMCPY_MAX for the maximum number of bytes to fold memcpy.
The default is
MOVE_MAX * MOVE_RATIO (optimize_function_for_size_p (cfun))
For x86, it is MOVE_MAX to restore the old behavior before
commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74
Author: Richard Earnshaw
Date: Fri
Hi Mikael,
Am 28.02.22 um 22:38 schrieb Mikael Morin:
Le 28/02/2022 à 22:32, Mikael Morin a écrit :
So please use a condition on expr->ts.type instead.
I said «instead», but «as well» is more appropriate; both expr.ts.type
and expr.ts.u.derived conditions are probably necessary.
I do hope
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a function call means it comes with bloated debug info, which
persists even after the call has been inlined away, for an operation that
is never interesting to debug.
This patch addresses this problem in a
The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive even if single-threaded.
There was already
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
> On 2/22/22 17:46, Marek Polacek wrote:
> > Here we have a forward declaration of Parameter for which we create
> > an implicit typedef, which is a TYPE_DECL. Then, when looking it up
> > at template definition time,
On Feb 23, 2022, Alexandre Oliva wrote:
> On Feb 21, 2022, Richard Biener wrote:
>>> Ok to revert commit r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
>> OK. Please re-open the bug as appropriate.
> Thanks. I've reopened it. Here's what I'm installing. I'm not
> reverting the
> Am 01.03.2022 um 20:08 schrieb Martin Sebor via Gcc-patches
> :
>
> On 3/1/22 11:41, Jakub Jelinek wrote:
>> Hi!
>> The following testcase emits bogus -Wdangling-pointer warnings.
>> The bug is that when it sees that ptr immediate use is a call that
>> returns one of its arguments, it will
On Mon, 2022-02-28 at 22:21 -0500, Michael Meissner wrote:
> Optimize signed DImode -> TImode on power10, PR target/104698.
>
Hi,
Logic seems OK to me, a few suggestions on the comments intermixed
below. As always, i defer if there are counter arguments. :-)
> On power10, GCC tries to
On 3/1/22 11:41, Jakub Jelinek wrote:
Hi!
The following testcase emits bogus -Wdangling-pointer warnings.
The bug is that when it sees that ptr immediate use is a call that
returns one of its arguments, it will assume that the return value
is based on ptr, but that is the case only if ptr is
Hi!
I've noticed various spelling bugs in comments in this file.
There is one spot I haven't fixed:
"Otherwise, VAR is the auto variable
(including an unnamed temporary such as a compound literal) whose
lifetime's rended it dangling."
I'm afraid I don't know what it wanted to say, "lifetime
Hi!
The following testcase emits bogus -Wdangling-pointer warnings.
The bug is that when it sees that ptr immediate use is a call that
returns one of its arguments, it will assume that the return value
is based on ptr, but that is the case only if ptr is passed to the
argument that is actually
Hi!
The r12-7287-g1b71bc7c8b18bd1b change improved the -Wdeprecated
warning for C++, but regressed it for C, in particular in
gcc.dg/deprecated.c testcase we now report a type that actually isn't
deprecated as deprecated instead of the one that is deprecated.
The following change tries to find
Hi,
This patch removes gdc.test/dhry.d from the testsuite, that was merged
in from the sync with upstream 2.098.0.
This test is not well ported, and doesn't check anything useful.
Committed to mainline.
gcc/testsuite/ChangeLog:
PR d/104736
* gdc.test/runnable/dhry.d: Removed.
Use C++ RAII with make_temp_override in the C++ FE to automatically clear
currently_expanding_gimple_stmt.
gcc/
PR middle-end/104721
* cfgexpand.cc (expand_gimple_basic_block): Use make_temp_override
to clear currently_expanding_gimple_stmt automatically.
* tree.h
Hi!
Jakub, need your review/approval here, please:
On 2022-01-13T10:54:16+0100, I wrote:
> On 2019-05-08T14:51:57+0100, Julian Brown wrote:
>> - The "addressable" bit is set during the kernels conversion pass for
>>variables that have "create" (alloc) clauses created for them in the
>>
Limit PR 35513 tests to Linux since they fail on 32-bit Solaris/x86 with
Solaris linker.
PR testsuite/104725
* g++.target/i386/pr35513-1.C: Limit to Linux.
* g++.target/i386/pr35513-2.C: Likewise.
---
gcc/testsuite/g++.target/i386/pr35513-1.C | 2 +-
Pushed to master as obvious. Right now, there are 3 linkers that
can utilize the plug-in, not only gold.
Martin
lto-plugin/ChangeLog:
* lto-plugin.c (process_offload_section): Use a linker as many
comments are connected to gold linker.
(process_option): Likewise.
---
So, if I try to sum up what has been gathered in this thread:
- pr104131.f90 is invalid, as x is not scalar.
Checks are better done in resolve_omp_clauses after a call
to gfc_resolve_expr.
Checking expr->sym->attr.dimension seems to cover more cases than
expr->rank > 0.
-
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This fixes a false positive warning seen with LTO:
12/bits/regex_compiler.tcc:443:32: error: '__last_char._M_char' may be used
uninitialized [-Werror=maybe-uninitialized]
Given that the std::regex code is not very efficient anyway, the
Hi,
This is the 2nd version of the patch based on the discussion on the initial
version.
Compared to the previous version, the major changes in this version are:
1. Merged two patches into one;
2. Re-organize the code to emit both Wswitch-unreachable and
Wtrivial-auto-var-init
On Mon, Feb 28, 2022 at 9:36 PM Hongtao Liu wrote:
>
> On Tue, Mar 1, 2022 at 10:39 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > On Mon, Feb 28, 2022 at 6:26 PM H.J. Lu wrote:
> > >
> > > On Mon, Feb 28, 2022 at 6:03 PM liuhongt wrote:
> > > >
> > > > .. in ix86_expand_vector_move and
> > > >
Hi,
This patch fixes a compilation error on x86_64-w64-mingw32.
Committed to mainline, and backported to releases/gcc-11.
Regards
Iain
---
libphobos/ChangeLog:
PR d/104659
* libdruntime/config/mingw/msvc.c (init_msvc): Fix misspelling of
msvcUsesUCRT.
---
Segher Boessenkool writes:
Hi!
> Hi!
>
> On Thu, Feb 24, 2022 at 03:48:54PM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>> > That is the problem yes. You need insns to call insn_cost on. You can
>> > look in combine.c:combine_validate_cost to see how this can be done; but
>> > you
On Tue, 1 Mar 2022, Richard Biener wrote:
> The following checks whether we can copy the loop before attempting
> to do so in loop distribution. In the testcase there's a computed
> goto and thus abnormal edges which we cannot redirect.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in
We need to be able to reverse a vector for negative strides.
Tested on x86_64-unknown-linux-gnu, pushed.
2022-03-01 Richard Biener
PR testsuite/104728
* gcc.dg/vect/pr81196-2.c: Require vect_perm.
---
gcc/testsuite/gcc.dg/vect/pr81196-2.c | 2 ++
1 file changed, 2
tested on x86_64-unknown-linux-gnu, pushed.
2022-03-01 Richard Biener
PR testsuite/104727
* gcc.target/i386/pr84101.c: Remove XFAIL.
---
gcc/testsuite/gcc.target/i386/pr84101.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Thanks you, Kito!
After Zmmul finishes the public review and merge into
riscv/riscv-isa-manuel, I will send a new patch if anything changes.
Liao Shihua
-原始邮件-
发件人: "Kito Cheng"
发送时间: 2022-03-01 21:59:47 (星期二)
收件人: "廖仕华"
抄送: "GCC Patches" , "Philipp Tomsich"
, jiawei
主题:
LGTM for GCC 13, I'll commit that once stage 1 is open again.
On Mon, Feb 14, 2022 at 10:26 AM wrote:
>
> From: LiaoShihua
>
> ZMMUL extension is Multiply only extension for RISC-V.It implements the
> multiplication subset of the M extension.
> The encodings are identical to those
> > diff --git a/gcc/testsuite/gcc.target/riscv/zbkb64.c
> > b/gcc/testsuite/gcc.target/riscv/zbkb64.c
> > new file mode 100644
> > index 000..2cd76a29750
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/zbkb64.c
> > @@ -0,0 +1,21 @@
> > +/* { dg-do compile } */
> > +/* {
Richard Biener writes:
> On Tue, 1 Mar 2022, Jiufu Guo wrote:
>
>> Segher Boessenkool writes:
>>
>> > On Thu, Feb 24, 2022 at 09:50:28AM +0100, Richard Biener wrote:
>> >> On Thu, 24 Feb 2022, Jiufu Guo wrote:
>> >> > And another thing as Segher pointed out, CSE is doing too
>> >> > much work.
On Wed, Feb 16, 2022 at 2:56 PM Patrick Palka wrote:
>
> On Tue, 15 Feb 2022, Jason Merrill wrote:
>
> > On 2/14/22 11:32, Patrick Palka wrote:
> > > Here the template context for the atomic constraint has two levels of
> > > template arguments, but since it depends only on the innermost argument
On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote:
>
> name_lookup::search_unqualified uses a statically allocated vector
> in order to avoid repeated reallocation, under the assumption that
> the function can't be called recursively. With modules however,
> this assumption turns out to be
Just one general review comment for this patch:
- Add newline at end of this file to prevent "\ No newline at end of
file" in the git commit log
- I saw you've skip -g and -flto, I guess that because that cause fail
since -g or -flto might add few more line to make the
scan-assembler-times, I
Committed as obvious (in hindsight).
2022-03-01 Roger Sayle
gcc/testsuite/ChangeLog
* gcc.target/i386/pr80270.c: Don't compile new test case on ia32.
Sorry for the noise.
Roger
--
diff --git a/gcc/testsuite/gcc.target/i386/pr80270.c
b/gcc/testsuite/gcc.target/i386/pr80270.c
index
On Linux/x86_64,
7e5c6edeb1b2339e10f10bee270e61dbad985800 is the first bad commit
commit 7e5c6edeb1b2339e10f10bee270e61dbad985800
Author: Roger Sayle
Date: Mon Feb 28 22:26:43 2022 +
PR middle-end/80270: ICE in extract_bit_field_1
caused
FAIL: gcc.target/i386/pr80270.c (test for
On Linux/x86_64,
ec1b9ba2d7913fe5e9deacc8e55e7539262f5124 is the first bad commit
commit ec1b9ba2d7913fe5e9deacc8e55e7539262f5124
Author: Vladimir N. Makarov
Date: Mon Feb 28 16:43:50 2022 -0500
[PR104637] LRA: Split hard regs as many as possible on one subpass
caused
FAIL:
Hi,
> Sorry, just realised I'd never replied to this.
No worries! I also took a very long time to reply, sorry.
> The problem is that we only enforce lane bounds via calls to
> __builtin_aarch64_im_lane_boundsi. In previous releases, the check
> only happend at RTL expansion time, so the check
First, thanks for looking into the standard. I think the information is
too much spread through the standard. I keep searching for restrictions,
find them at 5 places and miss another 5. With OpenMP 5.2, it became
even worse.
On 01.03.22 09:16, Jakub Jelinek wrote:
As there is no explicit
The following checks whether we can copy the loop before attempting
to do so in loop distribution. In the testcase there's a computed
goto and thus abnormal edges which we cannot redirect.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
2022-03-01 Richard Biener
PR
On Mon, Feb 28, 2022 at 2:27 PM Martin Liška wrote:
>
> The patch moves attribute checking to handle_target_clones_attribute where
> we drop the attribute if it contains only a single value.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
On Mon, Feb 28, 2022 at 10:39 AM Martin Liška wrote:
>
> This makes documentation more precise.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR gcov-profile/104677
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document more .gcda file name generation.
> ---
>
On Mon, Feb 28, 2022 at 10:03 AM Martin Liška wrote:
>
> Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
> so we need to drop it if we are called from optimize attribute and the
> option is unset.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
Hi Claudiu,
> The patch looks good. Please go ahead and merge it, please let me know if
> you cannot.
I merged the patch leaving your check
if (cmode != SImode && cmode != SFmode && cmode != DFmode)
return NULL_RTX;
in place. It is not strictly necessary anymore but I figured it also
On Tue, Mar 01, 2022 at 08:58:54AM +0100, Tobias Burnus wrote:
> The wording actually also permits array sections. But contrary to coarrays,
> (which are odd but otherwise fine), I think it does not really make sense
> to have arrays and array sections here.
>
> (Do we need/want to get this
Hi,
For a test-case doing an openmp target simd reduction on a complex double:
...
DOUBLE COMPLEX :: counter_N0
...
!$OMP TARGET SIMD reduction(+: counter_N0)
...
we run into:
...
during RTL pass: expand
b.f90: In function ‘MAIN__._omp_fn.0’:
b.f90:23:32: internal compiler error: in
Hi,
Use nvptx-sm.def to generate new files nvptx-gen.h and nvptx-gen.opt, and:
- include nvptx-gen.h in nvptx.h, and
- add nvptx-gen.opt to extra_options (before nvptx.opt, in case that matters).
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[nvptx] Add nvptx-gen.h and nvptx-gen.opt
Hi,
Add a script gen-omp-device-properties.sh that uses nvptx-sm.def to generate
omp-device-properties-nvptx.
Tested on x86_64 with nvptx accelerator.
Committed to trunk.
Thanks,
- Tom
[nvptx] Use nvptx-sm.def for t-omp-device
gcc/ChangeLog:
2022-02-25 Tom de Vries
*
Hi,
Add a file gcc/config/nvptx/nvptx-sm.def that lists all sm_xx versions used in
the port, like so:
...
NVPTX_SM(30, NVPTX_SM_SEP)
NVPTX_SM(35, NVPTX_SM_SEP)
NVPTX_SM(53, NVPTX_SM_SEP)
NVPTX_SM(70, NVPTX_SM_SEP)
NVPTX_SM(75, NVPTX_SM_SEP)
NVPTX_SM(80,)
...
and use it in various places using a
Hi,
Add a few test-cases that test passing each -misa=sm_xx version and verify that
the proper __PTX_SM__ is defined.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[nvptx, testsuite] Add gcc.target/nvptx/sm*.c
gcc/testsuite/ChangeLog:
2022-02-25 Tom de Vries
*
57 matches
Mail list logo
