On 28.02.22 22:37, Jakub Jelinek via Fortran wrote:
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
In my reading of the spec, pr104131-2.f90 is _valid_ (in newer OMP). At
least
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. It may be ok to separate the cons
> Am 01.03.2022 um 04:27 schrieb H.J. Lu via Gcc-patches
> :
>
> commit a5883ba0de68efad36db145e75c86394d8bd44ea
> Author: Michael Matz
> Date: Tue Nov 24 15:37:32 2009 +
>
> introduced currently_expanding_gimple_stmt, which was set and cleared in
> expand_gimple_basic_block when expa
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 BE and LE with no regressions. Is this
okay for trunk?
Any recommend
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
> > > ix86_convert_const_wide_int_to_broadcast(called by the former).
> > >
> >
This improves diagnostic quality for unsatisfied atomic constraints
that consist of a fold expression, e.g. in concepts/diagnostics3.C:
.../diagnostic3.C:10:22: note: the expression ‘(foo && ...) [with Ts =
{int, char}]’ evaluated to ‘false’
10 | requires (foo && ...)
| ~~
On Tue, 19 Jan 2021, Jason Merrill wrote:
> On 1/13/21 12:05 PM, Patrick Palka wrote:
> > In the below testcase, the expression of the atomic constraint after
> > substitution is (int *) NON_LVALUE_EXPR <1> != 0B which is not a C++
> > constant expression, but its TREE_CONSTANT flag is set (from b
On Tue, Feb 8, 2022 at 4:35 AM Maciej W. Rozycki wrote:
> gcc/
> * config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New
> constants.
> (fmin3, fmax3): New insns.
> ...
I tried testing on some of the hardware I have. Both the HiFive Unleashed
(2018) and HiFive U
commit a5883ba0de68efad36db145e75c86394d8bd44ea
Author: Michael Matz
Date: Tue Nov 24 15:37:32 2009 +
introduced currently_expanding_gimple_stmt, which was set and cleared in
expand_gimple_basic_block when expanding gimple statement to RTL. But it
isn't cleared when expand_gimple_basic_blo
Optimize signed DImode -> TImode on power10, PR target/104698.
On power10, GCC tries to optimize the signed conversion from DImode to
TImode by using the vextsd2q instruction. However to generate this
instruction, it would have to generate 3 direct moves (1 from the GPR
registers to the altivec r
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. It may be ok to separate the constant handling
>> > logic from CSE.
>>
>> Not sure
On Tue, Mar 1, 2022 at 10:27 AM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Feb 28, 2022 at 6:03 PM liuhongt wrote:
> >
> > .. in ix86_expand_vector_move and
> > ix86_convert_const_wide_int_to_broadcast(called by the former).
> >
> > ix86_expand_vector_move is called by emit_move_insn which is use
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
> > ix86_convert_const_wide_int_to_broadcast(called by the former).
> >
> > ix86_expand_vector_move is called by emit_move_insn which is used by
> > many pr
On Mon, Feb 28, 2022 at 6:03 PM liuhongt wrote:
>
> .. in ix86_expand_vector_move and
> ix86_convert_const_wide_int_to_broadcast(called by the former).
>
> ix86_expand_vector_move is called by emit_move_insn which is used by
> many pre_reload passes, ix86_gen_scratch_sse_rtx will break data flow
>
.. in ix86_expand_vector_move and
ix86_convert_const_wide_int_to_broadcast(called by the former).
ix86_expand_vector_move is called by emit_move_insn which is used by
many pre_reload passes, ix86_gen_scratch_sse_rtx will break data flow
when there's explict usage of xmm7/xmm15/xmm31.
Bootstrapped
Le 28/02/2022 à 22:37, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
There is gfc_is_coindexed that
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
commit ec1b9ba2d7913fe5e9deacc8e55e7539262f5124
Author: Vladimir N. Makarov
Date: Mon Feb 28 16:43:50 2022 -0500
[PR104637] L
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.
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 21:37, Mikael Morin a écrit :
> > Maybe corank should be checked together with rank?
>
> Lesson learned today: expressions don’t have a corank.
> Does pr104131-2.f90 really need to be rejected?
OpenMP 5.2 says that de
Le 16/02/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference. This is demonstrated by Gerhard's testcase.
Steve an
Hi,
This patch merges the D front-end implementation with upstream dmd
cf63dd8e5, as well as the D runtime libraries with druntime caf14b0f,
and phobos 41aaf8c26, synchronizing with the release of 2.099.0-rc1.
D front-end changes:
- Import dmd v2.099.0-rc.1.
- The `main' can now return t
On Mon, Feb 28, 2022 at 6:36 PM Roger Sayle wrote:
>
>
> This patch is my proposed solution to PR tree-optimization/91384 which is
> a missed-optimization/code quality regression on x86_64. The problematic
> idiom is "if (r = -a)" which is equivalent to both "r = -a; if (r != 0)"
> and alternativ
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
Le 28/02/2022 à 19:38, Kwok Cheung Yeung a écrit :
In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from
the symtree. It then iterates through the ref elements - ref->type ==
REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
This is the expected behavior.
On Mon, 2022-02-28 at 18:47 +0100, Richard Biener wrote:
>
>
> > Am 28.02.2022 um 16:31 schrieb David Malcolm via Gcc-patches <
> > gcc-patches@gcc.gnu.org>:
> >
> > On Mon, 2022-02-28 at 12:49 +0100, Martin Liška wrote:
> > > Use flag_checking instead of CHECKING_P
> > > and run toplev::finali
On 28/02/2022 5:37 pm, Jakub Jelinek wrote:
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
It is true that the spots I saw in fortran/openmp.cc that test rank look
like:
if (!gfc_resolve_expr (el->expr)
|| el->expr->ts.type != BT_INTEGER || el->expr->rank !
Iain,
this is the second bug, also found in Folly and also not extracted to a
testcase. We were ICEing because we ended up tsubst_copying something
that had already been tsubst, leading to an assert failure (mostly such
repeated tsubsting is harmless).
We had a non-dependent co_await in a no
> Am 28.02.2022 um 16:31 schrieb David Malcolm via Gcc-patches
> :
>
> On Mon, 2022-02-28 at 12:49 +0100, Martin Liška wrote:
>> Use flag_checking instead of CHECKING_P
>> and run toplev::finalize only if there is not error seen.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives reg
Iain,
this is the first of 2 patches I needed on top of your github WIP
series. It is against GCC-10, but AFAICT will also be needed on trunk.
We were not descending into the object operand of COMPONENT_REF exprs,
and end up bitcopying a field out of a temporary, leading to badness.
The brea
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
> > It is true that the spots I saw in fortran/openmp.cc that test rank look
> > like:
> > if (!gfc_resolve_expr (el->expr)
> > || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0)
> > etc., so probably !gfc_r
This patch is my proposed solution to PR tree-optimization/91384 which is
a missed-optimization/code quality regression on x86_64. The problematic
idiom is "if (r = -a)" which is equivalent to both "r = -a; if (r != 0)"
and alternatively "r = -a; if (a != 0)". In this particular case, on
x86_64,
Le 28/02/2022 à 17:00, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
(..
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. It may be ok to separate the constant handling
> > logic from CSE.
>
> Not sure - CSE just is value numbering, I don
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 need to have some code to generate in the fi
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, cp_parser_template_id gets (since r12-6754)
this TYPE_DECL which it can't handle.
Hmm, get
On Mon, Feb 28, 2022 at 04:30:01PM +, Iain Sandoe wrote:
>
>
> > On 28 Feb 2022, at 16:13, Jason Merrill wrote:
> >
> > On 2/25/22 17:59, Marek Polacek wrote:
> >> [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose
> >> it. ]
> >> When looking into the other PR I not
> On 28 Feb 2022, at 16:13, Jason Merrill wrote:
>
> On 2/25/22 17:59, Marek Polacek wrote:
>> [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose
>> it. ]
>> When looking into the other PR I noticed that we fail to give a warning
>> for a deprecated enumerator when the
On 2/28/22 12:22, Marek Polacek wrote:
On Mon, Feb 28, 2022 at 12:16:47PM -0400, Jason Merrill wrote:
On 2/25/22 17:59, Marek Polacek wrote:
When processing a template, the enumerators we build don't have a type
yet. But is_late_template_attribute is not prepared to see a _DECL
without a type,
On Mon, Feb 28, 2022 at 12:16:47PM -0400, Jason Merrill wrote:
> On 2/25/22 17:59, Marek Polacek wrote:
> > When processing a template, the enumerators we build don't have a type
> > yet. But is_late_template_attribute is not prepared to see a _DECL
> > without a type, so we crash on
> >
> >e
On Mon, Feb 28, 2022 at 12:13:36PM -0400, Jason Merrill wrote:
> On 2/25/22 17:59, Marek Polacek wrote:
> > [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose
> > it. ]
> >
> > When looking into the other PR I noticed that we fail to give a warning
> > for a deprecated enum
On 2/25/22 17:59, Marek Polacek wrote:
When processing a template, the enumerators we build don't have a type
yet. But is_late_template_attribute is not prepared to see a _DECL
without a type, so we crash on
enum tree_code code = TREE_CODE (type);
(I found that we don't give the "is depreca
On 2/25/22 17:59, Marek Polacek wrote:
[ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose it. ]
When looking into the other PR I noticed that we fail to give a warning
for a deprecated enumerator when the enum is in a class template. This
only happens when the attribute d
On Wed, Feb 23, 2022 at 5:46 PM wrote:
>
> From: LiaoShihua
>
>
> gcc/ChangeLog:
>
> * config/riscv/predicates.md (bs_operand): operand for bs
> (rnum_operand):
> * config/riscv/riscv.md: include crypto.md
> * config/riscv/crypto.md: New file.
>
> Co-Authored-By: W
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
> > On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
> (...)
> > > Don't we usually test instead || (*expr)->rank != 0 when testing for
> > > scalars?
> > >
> (...)
> >
> > So (*expr)->ra
and could you separate this from this patch series, I would like to
include this into GCC 12, and defer other stuffs to GCC 13
On Thu, Feb 24, 2022 at 5:55 PM Kito Cheng wrote:
>
> I would suggest implementing that in riscv_subset_list::parse so that
> it also affect the ELF attribute emission.
>
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
(...)
So (*expr)->rank is 0 here even with an array. I'm not sure why - is
rank updated later, or did we forget
Those header files have license issues that should relicinced to GPL,
and don't put rvk_asm_intrin.h rvk_emu_intrin.h, since they are not
too meaningful when we have compiler support.
General comment:
- Use /* */ rather than //, that gives much more compatibility, that
is illegal for c89.
- Add a
On Mon, Feb 28, 2022 at 9:59 AM Hongyu Wang wrote:
>
> Hi,
>
> For V8HFmode vector init with HFmode, do not directly emits V8HF move
> with subreg, which may cause reload to assign general register to move
> src.
>
> Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for master?
>
> gcc/C
On Mon, 2022-02-28 at 12:49 +0100, Martin Liška wrote:
> Use flag_checking instead of CHECKING_P
> and run toplev::finalize only if there is not error seen.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
Did the testing include the libgccjit test suite? ("jit" is no
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 19142c4d8d0..50a1c476009 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -531,9 +531,10 @@ gfc_match_o
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
> gcc/fortran/
>
> PR fortran/104131
> * openmp.cc (gfc_match_omp_detach): Check that the event handle is not
> an array type.
>
> gcc/testsuite/
>
> PR fortran/104131
> * gfortran.dg/gomp/pr104131.f
Hello
This patch addresses PR fortran/104131 on the GCC bug tracker, where an
ICE would occur if an array or co-array was passed as the event handle
in the detach clause of a task.
Since the event handle is supposed to be a scalar of type
omp_event_handle_kind, we can simply reject the event
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?
Thanks,
Martin
PR ipa/104533
gcc/c-family/ChangeLog:
On Mon, Feb 28, 2022 at 12:49 PM Martin Liška wrote:
>
> Use flag_checking instead of CHECKING_P
> and run toplev::finalize only if there is not error seen.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
>
On Mon, 28 Feb 2022, Tobias Burnus wrote:
> Ping**3
>
> On 23.02.22 09:42, Tobias Burnus wrote:
> > PING**2 for the ME review or at least comments to that patch,
> > which fixes a build issue/ICE with nvptx
> >
> > Patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html
> >
On Mon, 28 Feb 2022, Tamar Christina wrote:
> Hi All,
>
> The GCC 12 testsuite for complex numbers pattern recognition is a lot more
> exhaustive than the GCC 11 one. This backports the testsuite to GCC 11 so
> any further changes to the branch prevents regressions.
>
> Bootstrapped Regtested o
On Mon, 28 Feb 2022, Tamar Christina wrote:
> Hi All,
>
> GCC 11 handled negations rather differently than GCC 12. This difference
> caused the previous backport to regress some of the conjugate cases that it
> used to handle before. The testsuite in GCC 11 wasn't as robust as that in
> master
Hi Robin,
The patch looks good. Please go ahead and merge it, please let me know if
you cannot.
Thank you,
Claudiu
On Mon, Feb 21, 2022 at 9:57 AM Robin Dapp via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi,
>
> I figured I'd just go ahead and post this patch as well since it seems
> to h
Use flag_checking instead of CHECKING_P
and run toplev::finalize only if there is not error seen.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR ipa/104648
gcc/ChangeLog:
* main.cc (main): Use flag_checking inste
Hi All,
The GCC 12 testsuite for complex numbers pattern recognition is a lot more
exhaustive than the GCC 11 one. This backports the testsuite to GCC 11 so
any further changes to the branch prevents regressions.
Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regres
Hi All,
GCC 11 handled negations rather differently than GCC 12. This difference
caused the previous backport to regress some of the conjugate cases that it
used to handle before. The testsuite in GCC 11 wasn't as robust as that in
master so it didn't catch it.
The second patch in this series b
The following reverts a part of the PR103037 fix which is no longer necessary
after the fix for PR104700. That makes the possible cummulative backport
smaller.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-02-28 Richard Biener
* tree-ssa-pre.cc (compute_avail): Re
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check with no new failures. Ok for mainline?
>
>
> 2022-02-27 Roger Sayle
>
> gcc/ChangeLog
> PR middle-end/80270
> * expmed.cc (extract_integral_bit_field): If OP0 is a hard
> register, c
On Sat, 26 Feb 2022, Qing Zhao wrote:
> Hi,
>
> This is the 4th version based on the discussion so far.
>
> The major change is:
>
> > SET_EXPR_LOCATION (tmp_dst, UNKNOWN_LOCATION);
> > suppress_warning (tmp_dst, OPT_Wuninitialized);
> > with a comment explaing why we do that.
>
>
> The
Test must check for effective support of fpic.
Tested on x86_64-pc-linux-gnu{-m32,}.
ok for master?
gcc/testsuite/ChangeLog:
* gcc/gcc.target/i386/pr103275.c: Add missing
dg-require-effective-target for checking fpic.
---
gcc/testsuite/gcc.target/i386/pr103275.c | 1 +
1 file
On Feb 28 2022, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 28, 2022 at 04:27:19PM +0800, Xi Ruoyao wrote:
>> On Mon, 2022-02-28 at 07:06 +0100, Jakub Jelinek via Gcc-patches wrote:
>> > +++ libatomic/Makefile.am 2022-02-25 17:25:16.298314196 +0100
>> > @@ -138,8 +138,9 @@ IFUNC_OPTIO
Hi Robin,
I don't know how I missed your arc related patch, I'll bootstrap and test
your patch asap.
Thanks,
Claudiu
On Fri, Feb 25, 2022 at 3:29 PM Robin Dapp wrote:
> > If the movcc comparison is not valid it triggers an assert in the
> > current implementation. This behavior is not needed
Ping**3
On 23.02.22 09:42, Tobias Burnus wrote:
PING**2 for the ME review or at least comments to that patch,
which fixes a build issue/ICE with nvptx
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html
(for gcc/cfgexpand.cc + gcc/expr.cc)
(There is some discussion by To
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.
---
gcc/doc/invoke.texi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a
The following refactors find_or_generate_expression to more properly
handle constant valued SSA names thereby simplifying the code and
avoiding ICEing after the last change to NARY processing.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-02-28 Richard Biener
PR tr
On Mon, Feb 28, 2022 at 04:27:19PM +0800, Xi Ruoyao wrote:
> On Mon, 2022-02-28 at 07:06 +0100, Jakub Jelinek via Gcc-patches wrote:
> > +++ libatomic/Makefile.am 2022-02-25 17:25:16.298314196 +0100
> > @@ -138,8 +138,9 @@ IFUNC_OPTIONS = -march=i586
> > libatomic_la_LIBADD += $(a
Hi,
When running with target board unix/-foffload=-mptx=3.1, we run into:
...
lto1: error: PTX version (-mptx) needs to be at least 4.2 to support \
selected -misa (sm_53)^M
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned \
1 exit status^M
compilation terminated.^M
Hi,
When running with target board nvptx-none-run/-mptx=3.1, I run into:
...
cc1: error: PTX version (-mptx) needs to be at least 4.2 to support selected \
-misa (sm_53)^M
compiler exited with status 1
FAIL: gcc.target/nvptx/atomic-store-1.c (test for excess errors)
...
Fix this and similar cas
Hi,
Add an -mptx=_ value, that indicates the default ptx version.
It can be used to undo an explicit -mptx setting, so this:
...
$ gcc test.c -mptx=3.1 -mptx=_
...
has the same effect as:
...
$ gcc test.c
...
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[nvptx] Add -mptx=_
gcc/ChangeLo
Richard Biener writes:
> On Fri, 25 Feb 2022, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Fri, 25 Feb 2022, Jiufu Guo wrote:
>> >
>> >> Richard Biener writes:
>> >>
>> >> > On Thu, 24 Feb 2022, Jiufu Guo wrote:
>> >> >
>> >> >> Jiufu Guo via Gcc-patches writes:
>> >> >>
>> >> >>
Hi,
When running with target board nvptx-none-run/-misa=sm_70 I run into:
...
FAIL: gcc.target/nvptx/atomic-store-3.c scan-assembler-times st.global.u32 1
FAIL: gcc.target/nvptx/atomic-store-3.c scan-assembler-times st.global.u64 1
...
Fix this by adding an explicit -misa=sm_30 in the test-case.
Hi,
When running with target board nvptx-none-run/-misa=sm_53 we run into:
...
cc1: error: PTX version (-mptx) needs to be at least 4.2 to support selected \
-misa (sm_53)^M
compiler exited with status 1
FAIL: gcc.target/nvptx/uniform-simt-2.c (test for excess errors)
...
Fix this by adding an
Hi,
When running with target board nvptx-none-run/-misa=sm_30 we run into:
...
FAIL: gcc.target/nvptx/rotate.c scan-assembler-times shf.l.wrap.b32 1
FAIL: gcc.target/nvptx/rotate.c scan-assembler-times shf.r.wrap.b32 1
FAIL: gcc.target/nvptx/rotate.c scan-assembler-not and.b32
...
Fix this by add
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.
Ready to be installed?
Thanks,
Martin
PR middle-end/1043
Hi,
For V8HFmode vector init with HFmode, do not directly emits V8HF move
with subreg, which may cause reload to assign general register to move
src.
Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for master?
gcc/ChangeLog:
PR target/104664
* config/i386/i386-expand.cc
On 2/5/22 03:26, Allan McRae wrote:
On 5/2/22 01:22, Martin Liška wrote:
On 2/4/22 14:30, Jakub Jelinek via Gcc-patches wrote:
We don't ship any include-fixed headers in Fedora/RHEL.
Removing include-fixed from an installed folder, I see:
make[2]: Entering directory '/home/marxin/Programming
On Mon, 2022-02-28 at 07:06 +0100, Jakub Jelinek via Gcc-patches wrote:
> +++ libatomic/Makefile.am 2022-02-25 17:25:16.298314196 +0100
> @@ -138,8 +138,9 @@ IFUNC_OPTIONS = -march=i586
> libatomic_la_LIBADD += $(addsuffix _8_1_.lo,$(SIZEOBJS))
> endif
> if ARCH_X86_64
> -IFUNC_
82 matches
Mail list logo
