Hi,
Require effective target non_strict_prototype in a few test-cases.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Require non_strict_prototype in a few tests
gcc/testsuite/ChangeLog:
2022-02-10 Tom de Vries
* gcc.c-torture/compile/pr100576.c: Require
Hi,
Require effective target alloca in a few test-cases.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Require alloca support in a few tests
gcc/testsuite/ChangeLog:
2022-02-10 Tom de Vries
* c-c++-common/Walloca-larger-than.c: Require effective target alloca.
Hi,
With GOMP_NVPTX_JIT=-00 and -mptx=3.1, I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-version-1.c \
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 \
execution test
...
The problem is that we're generating a diverging branch around
Hi!
On Thu, Feb 10, 2022 at 04:28:02PM -0600, Bill Schmidt wrote:
> On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> >> No, trunk has this, for example:
> >>
> >> const signed int __builtin_altivec_vclzlsbb_v16qi (vsc);
> >> VCLZLSBB_V16QI vctzlsbb_v16qi {endian}
> > I see this on trunk:
> >
Hi!
On Thu, Feb 10, 2022 at 05:43:26PM -0500, David Edelsohn wrote:
> -mbig/-mlittle only applies to Linux, not AIX and not Darwin.
>
> I changed the BE testcases to add "-mbig" for little endian default
> targets because the compiler implicitly should be operating in big
> endian mode for other
On Fri, Feb 11, 2022 at 2:38 AM liuhongt wrote:
>
> >>> Confirmed. When uncond_op is expensive (there's *div amongst them) that's
> >>> definitely unwanted. OTOH when it is cheap then combining will reduce
> >>> latency.
> >>>
> >>> GIMPLE wise it's a neutral transform if uncond_op is not
On Thu, Feb 10, 2022 at 11:20 PM Thomas Schwinge
wrote:
>
> Hi!
>
> On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
> wrote:
> > On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
> >> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
> >> wrote:
> >> > OK to push (now, or in
Martin Sebor via Gcc-patches writes:
> The -Warray-bounds description in the manual is out of date in
> a couple of ways. First it claims that the option is only active
> with optimization, which isn't entirely correct since at least one
> instance is issued even without it. Second, the
On Fri, 11 Feb 2022 at 00:14, Jason Merrill wrote:
>
> On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote:
> > Hi!
> >
> > I wrote a patch for PR 25689, but I feel like it may not be the ideal
> > fix. Furthermore, there are some standing issues with the patch for
> > which I would like tips on
For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The
>>> Confirmed. When uncond_op is expensive (there's *div amongst them) that's
>>> definitely unwanted. OTOH when it is cheap then combining will reduce
>>> latency.
>>>
>>> GIMPLE wise it's a neutral transform if uncond_op is not single-use unless
>>> we need two v_c_es.
>>
>> We can leave it
The -Warray-bounds description in the manual is out of date in
a couple of ways. First it claims that the option is only active
with optimization, which isn't entirely correct since at least one
instance is issued even without it. Second, the description of
its level 2 suggests it controls the
On Thu, Feb 10, 2022 at 05:43:26PM -0500, David Edelsohn via Gcc-patches wrote:
> For the LE testcases, I changed the target selector to
> "powrpc*-*-linux*" because that is the only PowerPC target that can
> operate as little endian. I could not find a generic "le" target
> selector.
On Thu, Feb 10, 2022 at 10:57:02AM +0100, Richard Biener via Gcc-patches wrote:
> > >>> * g++.dg/warn/Wuninitialized-32.C: New testcase.
The testcase FAILs whenever size_t is not unsigned long:
FAIL: g++.dg/warn/Wuninitialized-32.C -std=c++98 (test for excess errors)
Excess errors:
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 can trigger -Wdangling-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not
On Thu, Feb 10, 2022 at 4:17 PM Bill Schmidt wrote:
>
> Hi!
>
> On 2/10/22 2:50 PM, Segher Boessenkool wrote:
> > On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> >> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> >> These built-ins were misimplemented
Hi!
On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote:
/* 1 argument vector functions added in ISA 3.0 (power9). */
-BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi)
-BU_P9V_AV_1 (VCLZLSBB_V8HI,
Hi!
On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
wrote:
> On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
>> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
>> wrote:
>> > OK to push (now, or in next development stage 1?) the attached
>> > "Consider 'TDF_UID',
Per Alan's comment in the bugzilla, fix attr-retain-* tescases for 32-bit
PowerPC.
Bootstrapped and regression tested on powerpc64(32/64) and powerpc64le.
Ok for master?
-Pat
2022-02-10 Pat Haugen
PR testsuite/100407
gcc/testsuite/
* gcc.c-torture/compile/attr-retain-1.c:
On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote:
> >> /* 1 argument vector functions added in ISA 3.0 (power9). */
> >> -BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi)
> >> -BU_P9V_AV_1 (VCLZLSBB_V8HI, "vclzlsbb_v8hi", CONST, vclzlsbb_v8hi)
> >>
Hi!
On 2/10/22 2:50 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
>>
>> Because the built-in
Some general observations:
* There are various toplevel GCC subdirectories that are built for the
host (possibly in addition to the target in some cases) but aren't changed
in this patch. Do they get a PIE or PIC build anyway by default? Such
directories include, I think: fixincludes (as a
On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> These built-ins were misimplemented as always having big-endian semantics.
>
> Because the built-in infrastructure has changed, the modifications to the
>
On Feb 10, 2022, Jakub Jelinek wrote:
> PR rtl-optimization/104459
> * df-scan.cc (df_insn_change_bb): Don't call df_set_bb_dirty when
> moving DEBUG_INSNs between bbs.
Thanks, that looks quite reasonable to me. I suppose if we can
reconsider a variant that distinguishes
This test regressed after my PR103752 patch with -march=cascadelake. I
don't understand why that flag makes a difference, but this patch is correct
in any case.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
Dear Fortranners,
when referencing a bad array section after an erroneous previous
declaration we might hit an assert. The assert can be replaced
by a more gracious error recovery. Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From
Hi!
On 2/10/22 2:06 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
> What is different
Hi!
On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> These built-ins were misimplemented as always having big-endian semantics.
What is different compared to the trunk version?
Segher
On Thu, Feb 10, 2022 at 06:23:58PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 10, 2022 at 10:42:03AM -0600, Segher Boessenkool wrote:
> > > Not on x86, that isn't a general auto-inc-dec target, but uses PRE_DEC
> > > etc. only for the sp hard register.
> >
> > Ugh. Does it have any benefit from
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of
On Linux/x86_64,
0f58ba4dd6b25b16d25494ae18d15dfa681f9b65 is the first bad commit
commit 0f58ba4dd6b25b16d25494ae18d15dfa681f9b65
Author: Richard Biener
Date: Fri Feb 4 09:46:43 2022 +0100
tree-optimization/104373 - early diagnostic on unreachable code
caused
FAIL:
Committed to trunk, backported to gcc-11.
On Wed, Feb 9, 2022 at 12:37 PM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 17:35, Thomas Rodgers via Libstdc++
> wrote:
> >
> > This patch changes the memory order used in the spin wait code to match
> > that of libc++.
>
> OK for trunk (and gcc-11
Hi!
This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
These built-ins were misimplemented as always having big-endian semantics.
Because the built-in infrastructure has changed, the modifications to the
source are different but achieve the same purpose. The
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7184-g2ac7b19f1e9219f46ccf55f25d8acb3e02e9a2d4.
gcc/analyzer/ChangeLog:
PR analyzer/98797
* region-model-manager.cc
(region_model_manager::maybe_fold_sub_svalue): Generalize getting
On Thu, Feb 10, 2022 at 06:35:05PM +0100, Tobias Burnus wrote:
> PR C++/102204
> gcc/cp/ChangeLog:
>
> * decl2.cc (cp_omp_mappable_type_1):
Description of the change is missing.
> libgomp/ChangeLog:
>
> * testsuite/libgomp.c++/target-virtual-1.C: New test.
>
>
This patch removes for C++ the OpenMP 4.5 requirement that
a class may not be mapped if there are virtual members.
It does not do anything beyond and, as RTTI is not accessible
(→ OpenMP 5.2) and restrictions exists on using virtual
functions (5.0/5.2), that seems to be fine for now.
OK? (For
On Thu, 10 Feb 2022, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch?
> The backport to the 10 branch hasn't been started yet, I figured it'd
> be good to first get the 11 backport right then base the 10 backport
> on the 11 one.
>
> NB: This backport of
On Thu, Feb 10, 2022 at 10:42:03AM -0600, Segher Boessenkool wrote:
> > Not on x86, that isn't a general auto-inc-dec target, but uses PRE_DEC
> > etc. only for the sp hard register.
>
> Ugh. Does it have any benefit from using autoinc at all then? (Actual
> benefit, not notational
On Tue, 08 Feb 2022 01:25:01 PST (-0800), sch...@linux-m68k.org wrote:
On Feb 07 2022, Palmer Dabbelt wrote:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0ebe538ccdc..5e8af05e359 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27702,7 +27702,7 @@ integer
On Thu, 10 Feb 2022, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch?
> The backport to the 10 branch hasn't been started yet, I figured it'd
> be good to first get the 11 backport right then base the 10 backport
> on the 11 one.
>
> NB: This backport of
Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch?
The backport to the 10 branch hasn't been started yet, I figured it'd
be good to first get the 11 backport right then base the 10 backport
on the 11 one.
NB: This backport of r12-1606 to the 11 branch deliberately omits parts
of
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by
r12-1606 bumped the value of __cpp_lib_ranges defined in ,
but this macro is also defined in , so it needs to
be updated there as well.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.
(cherry picked from commit
As promised in the --enable-host-pie patch, this patch adds another
configure option, --enable-host-bind-now, which adds -z now when linking
the compiler executables in order to extend hardening. BIND_NOW with RELRO
allows the GOT to be marked RO; this prevents GOT modification attacks.
This
This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE. This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.
It is similar to the option --enable-host-shared, except that --e-h-s
On Thu, Feb 10, 2022 at 05:21:07PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 10, 2022 at 10:10:13AM -0600, Segher Boessenkool wrote:
> > But we do have that in other cases, and not just for combine. IMO it
> > is a good idea to robustify for_each_inc_dec (simply have it skip if the
> > address is
2022-02-10 Uroš Bizjak
gcc/ChangeLog:
PR target/104469
* config/i386/sse.md (vec_unpacks_float_lo_v4si):
Change operand 1 constraint to register_operand.
gcc/testsuite/ChangeLog:
PR target/104469
* gcc.target/i386/pr104469.c: New test.
Bootstrapped and regression tested
Hi,
On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
> wrote:
> >
> > Hi!
> >
> > OK to push (now, or in next development stage 1?) the attached
> > "Consider 'TDF_UID', 'TDF_NOUID' in 'print_node_brief', 'print_node'",
> > or should
On Thu, Feb 10, 2022 at 10:10:13AM -0600, Segher Boessenkool wrote:
> > case POST_DEC:
> > {
> > poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
> > rtx r1 = XEXP (x, 0);
> > rtx c = gen_int_mode (-size, GET_MODE (r1));
> > return fn (mem, x, r1, r1, c,
On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote:
Hi!
I wrote a patch for PR 25689, but I feel like it may not be the ideal
fix. Furthermore, there are some standing issues with the patch for
which I would like tips on how to fix them.
Specifically, there are 2 issues:
1. GCC warns about
Hi!
On Thu, Feb 10, 2022 at 10:55:03AM +0100, Jakub Jelinek wrote:
> The following testcase ICEs, because combine substitutes
> (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
> (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
> (nil))
> (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI
PR target/104458
* gcc.target/i386/pr104458.c: Replace long with long long.
---
gcc/testsuite/gcc.target/i386/pr104458.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr104458.c
b/gcc/testsuite/gcc.target/i386/pr104458.c
index
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7180-g8383d41d704571d7ca234c7d2f551b7b69255194.
gcc/testsuite/ChangeLog:
PR analyzer/102052
* gcc.dg/analyzer/fields.c (size_t): Use __SIZE_TYPE__ rather than
hardcoding long unsigned int.
*
1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513
run-time tests.
2. Compile pr35513-8.c to scan assembly code.
PR testsuite/104481
* g++.target/i386/pr35513-1.C: Require property_1_needed target.
* g++.target/i386/pr35513-2.C: Likewise.
*
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This function (and the explicit memory over version) are present in both
C++ and C , so should be in C++ too.
There is a library issue incoming for this, but the resolution is
obvious.
libstdc++-v3/ChangeLog:
*
On Tue, 8 Feb 2022 at 21:18, Jonathan Wakely wrote:
>
>
> On Tue, 8 Feb 2022 at 21:02, Dimitar Dimitrov wrote:
>
>> On Mon, Feb 07, 2022 at 09:05:45PM +, Jonathan Wakely wrote:
>> > On Mon, 7 Feb 2022 at 21:01, Jonathan Wakely
>> wrote:
>> >
>> > >
>> > >
>> > > On Mon, 7 Feb 2022 at 20:12,
Hi Harald,
I have run your modified version of finalize_38.f90, and now I see
> that you can get a bloody head just from scratching too much...
>
> crayftn 12.0.2:
>
> 1, 3, 1
>
It appears that Cray interpret a derived type constructor as being a
function call and so "6 If a specification
Hi!
As mentioned in the PR, we get -fcompare-debug failure, which is caused by
cfg_layout_merge_blocks successfully merging two bbs where both bbs
contained just CODE_LABEL, NOTE_INSN_BASIC_BLOCK and in the -g case both
some debug insns at the end. cfg_layout_merge_blocks calls
On 10.02.22 11:07, Roger Sayle wrote:
The fix is to tweak trans-common.cc to respect the target's NO_DOT_IN_LABEL
(and NO_DOLLAR_IN_LABEL) when generating internal equiv.%d symbols.
In general, I think the patch is okay – but as '_' is a valid identifier
and with -fdollar-ok '$' is valid as
On Wed, 9 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 09, 2022 at 03:41:23PM +0100, Richard Biener wrote:
> > On Wed, 9 Feb 2022, Jakub Jelinek wrote:
> >
> > > On Wed, Feb 09, 2022 at 11:19:25AM +0100, Richard Biener wrote:
> > > > That does look like bogus abstraction though - I'd rather have
This patch fixes 9 unexpected failures in the gfortran testsuite on
nvptx-none. The issue is that gfortran's EQUIVALENCE internally uses
symbols such as "equiv.0" even on platforms that define NO_DOT_IN_LABEL.
On nvptx-none, this then results in the following error message(s):
ptxas application
On Wed, 9 Feb 2022, Martin Sebor wrote:
> On 2/9/22 00:12, Richard Biener wrote:
> > On Tue, 8 Feb 2022, Jeff Law wrote:
> >
> >>
> >>
> >> On 2/8/2022 12:03 AM, Richard Biener via Gcc-patches wrote:
> >>> The following improves early uninit diagnostics by computing edge
> >>> reachability using
Dan Li writes:
> On 2/9/22 08:08, Richard Sandiford wrote:
>> Dan Li writes:
>>> +
>>> + /* When shadow call stack is enabled, the scs_pop in the epilogue will
>>> + restore x30, and we don't need to pop x30 again in the traditional
>>> + way. Pop candidates record the registers that
Hi!
The following testcase ICEs, because combine substitutes
(insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
(const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
(nil))
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
(reg:SI 85)) "pr104446.c":10:3 56
This fixes a bogus vector type used for a CTOR build as part of
vector extract simplification. The code failed to consider a
CTOR of vector elements.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
2022-02-10 Richard Biener
PR middle-end/104467
* match.pd
On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge wrote:
>
> Hi!
>
> OK to push (now, or in next development stage 1?) the attached
> "Consider 'TDF_UID', 'TDF_NOUID' in 'print_node_brief', 'print_node'",
> or should that be done differently -- or, per the current state (why?)
> not at all?
>
> This
Hi,
Add spinlock test-cases for nvptx.
Strictly speaking, these are invalid openACC, because they're not guaranteed
to terminate.
But I've tested these without problems on cards from nvidia architectures
Kepler, Maxwell, Pascal and Turing (though on Turing, that's what you expect
given that
Hi,
The OpenACC execution model states that implementing a critical
section across workers using atomic operations and a busy-wait loop may never
succeed, since the scheduler may suspend the worker that owns the lock, in
which case the worker waiting on the lock can never complete.
Add a
Hi,
For sm_7x atomic stores we fall back on expand_atomic_store, but this
results in using membar.sys for shared stores.
Fix this by adding an nvptx_atomic_store insn that adds a membar.cta for a
shared store.
Tested on x86_64 with nvptx accelerator.
Committed to trunk.
Thanks,
- Tom
[nvptx]
Hi,
The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
locations do not guarantee atomicity with respect to normal store instructions
to the same address.
This can be fixed by:
- inserting barriers between normal stores and atomic operations to a common
address
-
The following fixes a cut error in disambiguating using restrict
info. Instead of using the for this purpose computed rbase1/rbase2
which preserve MEM_REF bases even when they are based on a decl the
code performs the check on the bases that drop info for those ...
Bootstrapped and tested on
Hi,
There's a nvidia driver JIT bug that mishandles this code (minimized from
builtin-arith-overflow-15.c):
...
int main (void) {
signed char r;
unsigned char y = (unsigned char) 0x80;
if (__builtin_sub_overflow ((unsigned char)0, (unsigned char)y, ))
__builtin_abort ();
return 0;
}
On 2/8/22 14:09, Roger Sayle wrote:
Many thanks to Thomas Schwinge for confirming my hypothesis that the
register
usage regression, PR target/104345, is solely due to libgcc's _muldc3
function.
In addition to the isinf functionality in the previously proposed nvptx
patch at
On 2/3/22 22:00, Roger Sayle wrote:
This patch addresses the "increased register pressure" regression on
nvptx-none caused by my change to transition the backend to a
STORE_FLAG_VALUE = 1 target. This improved code generation for the
more common case of producing 0/1 Boolean values,
On 1/16/22 12:49, Roger Sayle wrote:
This patch adds support for nvptx's BImode and.pred, or.pred and
xor.pred instructions. Technically, nvptx.md previously defined
andbi3, iorbi3 and xorbi3 instructions, but the assembly language
mnemonic output for these was incorrect (e.g. and.b1) and
On 1/14/22 10:54, Roger Sayle wrote:
Now that the middle-end MULT_HIGHPART_EXPR pieces are in place, this
patch adds support for nvptx's mul.hi.s64 and mul.hi.u64 instructions,
as previously reviewed (provisionally pre-approved) back in August 2020:
On 1/10/22 11:58, Roger Sayle wrote:
One of the unusual target features of the Nvidia PTX ISA is that it
doesn't provide QI mode (byte sized) operations or registers.
[ FWIW: I recently happened to check this, and it actually supports
.u8/.s8/.b8 regs, but indeed just for very few
Hi Maciej:
OK for release branches, thanks!
On Tue, Feb 8, 2022 at 8:24 PM Maciej W. Rozycki wrote:
>
> On Mon, 7 Feb 2022, Kito Cheng wrote:
>
> > OK to trunk, thanks for fixing this issue, I hit that issue before but
> > I didn't figure out what happened...since that issue will disappear
> >
On 1/8/22 13:21, Roger Sayle wrote:
This patch adds more support for _Float16 (HFmode) to the nvptx backend.
Currently negation, absolute value and floating point comparisons are
implemented by promoting to float (SFmode). This patch adds suitable
define_insns to nvptx.md, most conditional on
---
htdocs/frontends.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/frontends.html b/htdocs/frontends.html
index cd67b089..748ca182 100644
--- a/htdocs/frontends.html
+++ b/htdocs/frontends.html
@@ -32,7 +32,7 @@ are very mature.
gcc:
* doc/install.texi (Specific): Change the www.bitwizard.nl
reference to use https.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 93eae1f2582..7258f9def6c 100644
---
81 matches
Mail list logo
