Hi!
On 12/27/19 12:26 AM, John Paul Adrian Glaubitz wrote:
> For this reason, people have been asking for a Rust frontend for GCC similar
> to
> the one for Go. Now, there are actually two independent implementation of a
> Rust
> frontend for GCC [1, 2] being developed and I was wondering whethe
On 12/26/19 6:26 PM, John Paul Adrian Glaubitz wrote:
Hello!
The programming language Rust has become very popular over the past few years
with many projects rewriting parts of their codebase in that language. While
these rewrites often make the code perform faster and potentially safer, using
R
Hi Tobias,
Build on x86-64-gnu-linux without offloading and with nvptx offloading.
OK for the trunk?
I can't really say a lot about OpenACC, but the changes do look
reasonable.
So, OK for trunk.
Regards
Thomas
On December 28, 2019 5:31:20 PM GMT+01:00, Richard Sandiford
wrote:
>In this testcase we use an unmasked SVE loop with an Advanced SIMD
>epilogue (because we don't yet support fully-masked downward loops).
>The main loop uses a gather load for the strided access while the
>epilogue loop builds th
On December 28, 2019 5:29:20 PM GMT+01:00, Richard Sandiford
wrote:
>The EXTRACT_LAST_REDUCTION handling needs to generate a separate
>comparison instruction that feeds the vector mask argument of the
>IFN_EXTRACT_LAST call. We weren't checking whether that comparison
>was supported, leading to
In this testcase we use an unmasked SVE loop with an Advanced SIMD
epilogue (because we don't yet support fully-masked downward loops).
The main loop uses a gather load for the strided access while the
epilogue loop builds the access from scalars instead. In both cases
we gimplify expressions base
The EXTRACT_LAST_REDUCTION handling needs to generate a separate
comparison instruction that feeds the vector mask argument of the
IFN_EXTRACT_LAST call. We weren't checking whether that comparison
was supported, leading to an ICE on the testcase.
Tested on aarch64-linux-gnu and x86_64-linux-gnu.
On Sat, Dec 28, 2019 at 12:02 PM Jakub Jelinek wrote:
>
> On Sat, Dec 28, 2019 at 11:48:12AM +0100, Uros Bizjak wrote:
> > On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
> > >
> > > Hi!
> > >
> > > In i386.md, we have nearbyint2 and rint2 patterns that expand
> > > SF/DF/XF mode patterns t
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 1/3 is the GCC changes: Documentation and new avr-specific
configure options:
--with-libf7 selects to which level double support from libf7 is added
to libgcc.
--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
retur
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 3/3 is the actual libf7 implementation. A great deal of which is
assembly, together with C + inline assembly for higher routines.
Johann
libgcc/config/avr/libf7/
* t-libf7: New file.
* t-libf7-math: New file.
* t-libf7-m
Ping #1
Now that the avr backend can support 64-bit floats by means of
configure-options --with-double= and --with-long-double=, this patch
series adds some routines to support it.
It's an ad-hoc, avr-specific implementation in assembly and GNU-C which
is added as a new subfolder in libgcc/c
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 2/3 is the libgcc additions:
--with-libf7 selects which makefile-snips from libf7 to use.
libgcc/
* config.host (tmake_file) [target=avr]: Add t-libf7,
t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
*
Ping #1
Now that the avr backend can support 64-bit floats by means of
configure-options --with-double= and --with-long-double=, this patch
series adds some routines to support it.
It's an ad-hoc, avr-specific implementation in assembly and GNU-C which
is added as a new subfolder in libgcc/c
Ping #1.
Hi, this patch turns off -fipa-icf-variables because it generates wrong
code like for PR92606. As there is no target hook that could decide
whether such optimizations are obsolete, disable such optimizations
alltogether until PR92932 (target hook to disable such optimizations
depend
Ping #1
Hi, currently device support in avr-gcc is accomplished by injecting a
specs file my means of -specs=... in dirver self specs.
This patch adds a new avr driver option to omit the addition of
respective -specs option so give the user more freedom.
Ok to apply?
Johann
* config/a
On Sat, Dec 28, 2019 at 11:48:12AM +0100, Uros Bizjak wrote:
> On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > In i386.md, we have nearbyint2 and rint2 patterns that expand
> > SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
> > done using XFmode
On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> In i386.md, we have nearbyint2 and rint2 patterns that expand
> SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
> done using XFmode and so inappropriate for vectorization, but for sse4.1
> and later we can j
Hi!
In i386.md, we have nearbyint2 and rint2 patterns that expand
SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
done using XFmode and so inappropriate for vectorization, but for sse4.1
and later we can just use the {,v}{round,rndscale}p{s,d} instructions
when we emit {,v
Hi!
The r279710 commit added 4 libcuda calls that weren't used before, added
them properly to libgomp/plugin/cuda-lib.def but didn't add them to the
fallback cuda.h.
The following patch does that. Bootstrapped/regtested on x86_64-linux and
i686-linux, built and tested with x86_64-linux to nvptx-
19 matches
Mail list logo
