On Fri, Sep 3, 2021 at 10:55 AM Eric Botcazou wrote:
>
> Hi,
>
> packed array types are sometimes represented with integer types under the hood
> in Ada, but we nevertheless need to emit them as array types in the debug info
> so we have the types.get_array_descr_info langhook for this purpose; bu
On Mon, Sep 6, 2021 at 7:21 AM Sandra Loosemore
wrote:
> On 9/5/21 7:29 PM, H.J. Lu wrote:
> > On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
> > wrote:
> >>
> >> On 9/5/21 7:31 AM, H.J. Lu wrote:
> >>> On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore <
> san...@codesourcery.com> wrote:
>
On Mon, Sep 06, 2021 at 09:42:32AM +0800, Hongtao Liu wrote:
> > Also, shouldn't the *hf* and *hc* APIs be exported from libgcc_s.so.1?
> >
> >254: 00011960 968 FUNCLOCAL DEFAULT 13 __floattihf
> >256: 000116f0 315 FUNCLOCAL DEFAULT 13 __fixhfti
> >263:
On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
wrote:
>
> This patch abstracts out a couple common idioms in the forward
> threader that I found useful while navigating the code base.
>
> Tested on x86-64 Linux.
>
> OK?
>
> gcc/ChangeLog:
>
> * tree-ssa-threadedge.c (has_phi
ping?
On 26/08/2021 17:53, Christophe Lyon wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure this.
2021-08-26 Christophe Lyon
gcc/testsuite/
On Mon, Sep 6, 2021 at 4:48 AM Di Zhao OS wrote:
>
> If the first predicate value is different and copied, the comparison will
> then be between val->result and the copied one, which seems to be a bug. That
> can cause inserting extra vn_pvals.
>
> Bootstrapped and tested on x86_64-unknown-linux
Hi!
My earlier patch to demote arguments of __builtin_*_overflow unfortunately
caused a wrong-code regression. The builtins operate on infinite precision
arguments, outer_prec > inner_prec signed -> signed, unsigned -> unsigned
promotions there are just repeating the sign or 0s and can be demoted
On Mon, Sep 6, 2021 at 7:31 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> These two testcases have been failing since GCC 5 but things
> have improved such that adding a simplification to match.pd
> for this case is easier than before.
> In the end we have the following IR:
> .
> On 6 Sep 2021, at 08:08, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Mon, Sep 06, 2021 at 09:42:32AM +0800, Hongtao Liu wrote:
>>> Also, shouldn't the *hf* and *hc* APIs be exported from libgcc_s.so.1?
>>>
>>> 254: 00011960 968 FUNCLOCAL DEFAULT 13 __floattihf
>>> 25
On Mon, 6 Sep 2021, Jakub Jelinek wrote:
> Hi!
>
> My earlier patch to demote arguments of __builtin_*_overflow unfortunately
> caused a wrong-code regression. The builtins operate on infinite precision
> arguments, outer_prec > inner_prec signed -> signed, unsigned -> unsigned
> promotions ther
On Fri, Sep 03, 2021 at 01:36:36PM +0100, Iain Sandoe wrote:
> oops EWRONGPATCH
>
> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
> index cea33267e53..902a9364850 100644
> --- a/libgcc/libgcc-std.ver.in
> +++ b/libgcc/libgcc-std.ver.in
> @@ -1944,3 +1944,23 @@ GCC_7.0.0 {
>_
Hi:
As discussed in [1], most of (currently unopposed) targets want
auto-vectorization at O2, and IMHO now would be a good time to enable O2
vectorization for GCC trunk, so it would leave enough time to expose
related issues and fix them.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
On Mon, Sep 6, 2021 at 4:46 PM liuhongt via Gcc-patches
wrote:
>
> Hi:
> As discussed in [1], most of (currently unopposed) targets want
> auto-vectorization at O2, and IMHO now would be a good time to enable O2
> vectorization for GCC trunk, so it would leave enough time to expose
> related iss
On Mon, Sep 6, 2021 at 2:54 PM Richard Biener
wrote:
>
> On Thu, Sep 2, 2021 at 7:54 PM Richard Sandiford
> wrote:
> >
> > Hongtao Liu via Gcc-patches writes:
> > > On Wed, Sep 1, 2021 at 8:52 PM Richard Sandiford
> > > wrote:
> > >>
> > >> Richard Biener writes:
> > >> > On Wed, Sep 1, 2021 a
On Mon, Sep 06, 2021 at 08:49:27AM +0100, Iain Sandoe wrote:
> > Ok. The *.ver changes are still needed (see above), but that can be done
> > incrementally.
>
> I can commit the .ver change if that’s approved, sure - for the record I
> haven’t checked
> any targets other than Darwin and Linux.
On 2021/9/4 05:44, Segher Boessenkool wrote:
Hi!
On Fri, Sep 03, 2021 at 10:31:24AM +0800, Xionghu Luo wrote:
fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.
Thank you very much for this patch.
Some trivial comments
> OK, I suppose this should also help some Fortran array descriptor cases?
Thanks. This changes something only if array types in the source code are not
always represented by ARRAY_TYPEs in the IR.
--
Eric Botcazou
On Mon, Sep 6, 2021 at 10:47 AM liuhongt via Gcc-patches
wrote:
>
> Hi:
> As discussed in [1], most of (currently unopposed) targets want
> auto-vectorization at O2, and IMHO now would be a good time to enable O2
> vectorization for GCC trunk, so it would leave enough time to expose
> related is
Hi:
As discussed in [1], adjust the layout for x86 _Float16 description.
Bootstrappedn and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* doc/extend.texi: (@node Floating Types): Adjust the wording.
(@node Half-Precision): Ditto.
---
gcc/doc/extend.te
On Mon, Sep 6, 2021 at 5:19 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Sep 6, 2021 at 10:47 AM liuhongt via Gcc-patches
> wrote:
> >
> > Hi:
> > As discussed in [1], most of (currently unopposed) targets want
> > auto-vectorization at O2, and IMHO now would be a good time to enable O2
Hi:
For the conversion from _Float16 to int, if the corresponding optab
does not exist, the compiler will try the wider mode (SFmode here),
but when floatsfsi exists but FAIL, FROM will be rewritten, which
leads to a PR runtime error.
Boostrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok
On Mon, Sep 06, 2021 at 11:18:47AM +0200, Richard Biener wrote:
> On Mon, Sep 6, 2021 at 10:47 AM liuhongt via Gcc-patches
> wrote:
> >
> > Hi:
> > As discussed in [1], most of (currently unopposed) targets want
> > auto-vectorization at O2, and IMHO now would be a good time to enable O2
> > vec
Ping?
[PATCH v3] gcc_update: use human readable name for revision string in
gcc/REVISION
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575556.html
>
> OK for mainline?
>
> ---
> contrib/Changelog:
>
> * gcc_update: derive human readable name for HEAD using git describe
> like "
On Tue, Aug 31, 2021 at 4:10 PM Indu Bhagat via Gcc-patches
wrote:
>
> [Changes from V2]
> - Instead of target hook, the patch set now adds a new debug format
> BTF_WITH_CORE_DEBUG.
> - Renamed the BPF option from -mcore to -mco-re.
> - Adapted the commit logs a bit.
> [End of Changes from V2]
Th
On Mon, Sep 06, 2021 at 12:49:18PM +0300, Serge Belyshev wrote:
* gcc_update: derive human readable name for HEAD using git describe
After : start with upper case, ^^^ Derive
like "git gcc-descr" with short commit hash. Drop "revision" from
gcc/REVISION.
Too long line.
Otherwi
On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
wrote:
>
> On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
> [...]
> > > >
> > > > + /* Handle strlen like loops. */
> > > > + if (store_dr == NULL
> > > > + && integer_zerop (pattern)
> > > > + && TREE_CODE (
Hi!
On 2021-09-03T10:02:31+0200, Jakub Jelinek via Gcc-patches
wrote:
> When __atomic_* builtins were introduced, omp-expand.c (omp-low.c
> at that point) has been adjusted in several spots so that it uses
> the atomic builtins instead of sync builtins, but
> expand_omp_atomic_pipeline has not b
On Mon, 6 Sep 2021, liuhongt wrote:
> Hi:
> For the conversion from _Float16 to int, if the corresponding optab
> does not exist, the compiler will try the wider mode (SFmode here),
> but when floatsfsi exists but FAIL, FROM will be rewritten, which
> leads to a PR runtime error.
>
> Boostrap
On Sun, Sep 05, 2021 at 11:28:30PM +0100, Roger Sayle wrote:
> This patch simplifies the RTX (subreg:HI (truncate:QI (reg:SI))) as
> (truncate:HI (reg:SI)), and closely related variants.
Subregs of other than regs are undefined in RTL. You will first have to
define this (in documentation as well
On Sat, 21 Aug 2021, Qing Zhao wrote:
> Hi,
>
> This is the 8th version of the patch for the new security feature for GCC.
> I have tested it with bootstrap on both x86 and aarch64, regression testing
> on both x86 and aarch64.
> Also tested it with the kernel testing case provided by Kees.
> Al
Hi Sandra, hi all,
On 06.09.21 07:20, Sandra Loosemore wrote:
On 9/5/21 7:29 PM, H.J. Lu wrote:
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
wrote:
On 9/5/21 7:31 AM, H.J. Lu wrote:
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore
wrote:
The testcase gfortran.dg/PR100914.f90 that I re
On Mon, Sep 6, 2021 at 6:03 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, 6 Sep 2021, liuhongt wrote:
>
> > Hi:
> > For the conversion from _Float16 to int, if the corresponding optab
> > does not exist, the compiler will try the wider mode (SFmode here),
> > but when floatsfsi exists but
GCC was recently changed to prevent simplify_subreg from simplifying
a subreg of a mem when the mode of the new mem would have stricter alignment
constraints than the inner mem already has when the target requires
STRICT_ALIGNMENT.
However, such targets may have specialist patterns that can handl
The current restriction on folding memcpy to a single element of size
MOVE_MAX is excessively cautious on most machines and limits some
significant further optimizations. So relax the restriction provided
the copy size does not exceed MOVE_MAX * MOVE_RATIO and that a SET
insn exists for moving th
This short patch series is designed to address some more cases where we
can usefully lower memcpy operations during gimple fold. The current
code restricts this lowering to a maximum size of MOVE_MAX, ie the size
of a single integer register on the machine, but with modern architectures
this is li
DImode is currently handled only for machines with vector modes
enabled, but this is unduly restrictive and is generally better done
in core registers.
gcc/ChangeLog:
PR target/102125
* config/arm/arm.md (movmisaligndi): New define_expand.
* config/arm/vec-common.md (movm
On Mon, 6 Sep 2021, Hongtao Liu wrote:
> On Mon, Sep 6, 2021 at 6:03 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Mon, 6 Sep 2021, liuhongt wrote:
> >
> > > Hi:
> > > For the conversion from _Float16 to int, if the corresponding optab
> > > does not exist, the compiler will try the wid
On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote:
>
>
> The current restriction on folding memcpy to a single element of size
> MOVE_MAX is excessively cautious on most machines and limits some
> significant further optimizations. So relax the restriction provided
> the copy size does not e
On Mon, Sep 6, 2021 at 5:42 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Sep 06, 2021 at 11:18:47AM +0200, Richard Biener wrote:
> > On Mon, Sep 6, 2021 at 10:47 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > As discussed in [1], most of (currently unopposed) targets want
>
Hi all,
gfortran's internal array descriptor (xgfc descriptor) and
the descriptor used with BIND(C) (CFI descriptor, ISO_Fortran_binding.h
of TS29113 / Fortran 2018) are different. Thus, when calling a BIND(C)
procedure the gfc descriptor has to be converted to cfi – and when a
BIND(C) procedure
On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote:
>
>
> GCC was recently changed to prevent simplify_subreg from simplifying
> a subreg of a mem when the mode of the new mem would have stricter alignment
> constraints than the inner mem already has when the target requires
> STRICT_ALIGNMENT
On Mon, Sep 06, 2021 at 06:58:37PM +0800, Hongtao Liu wrote:
> > process_options would mean it affects only the command line and not
> > __attribute__((optimize ("O2", "ftree-vectorize")))
> > etc.
> > So, shouldn't it be instead done in default_options_optimization, somewhere
> It seems default_op
On Mon, Sep 6, 2021 at 11:41 AM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 11:18:47AM +0200, Richard Biener wrote:
> > On Mon, Sep 6, 2021 at 10:47 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > As discussed in [1], most of (currently unopposed) targets want
> > > auto-vecto
On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote:
On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote:
GCC was recently changed to prevent simplify_subreg from simplifying
a subreg of a mem when the mode of the new mem would have stricter alignment
constraints than the inner me
On Mon, Sep 6, 2021 at 7:01 PM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 06:58:37PM +0800, Hongtao Liu wrote:
> > > process_options would mean it affects only the command line and not
> > > __attribute__((optimize ("O2", "ftree-vectorize")))
> > > etc.
> > > So, shouldn't it be instead done
On Mon, Sep 6, 2021 at 12:15 PM Segher Boessenkool
wrote:
>
> On Sun, Sep 05, 2021 at 11:28:30PM +0100, Roger Sayle wrote:
> > This patch simplifies the RTX (subreg:HI (truncate:QI (reg:SI))) as
> > (truncate:HI (reg:SI)), and closely related variants.
>
> Subregs of other than regs are undefined
On Mon, Sep 6, 2021 at 1:08 PM Richard Earnshaw
wrote:
>
>
>
> On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote:
> > On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote:
> >>
> >>
> >> GCC was recently changed to prevent simplify_subreg from simplifying
> >> a subreg of a mem when the
On Mon, Sep 06, 2021 at 07:15:41PM +0800, Hongtao Liu wrote:
> > So what about finish_options then?
> > default_options_optimization has only a single caller that then calls
> > read_cmdline_options and then finish_options.
> in finish_options
> (gdb) p opts_set->x_flag_tree_loop_vectorize
> $37 =
On 06/09/2021 12:13, Richard Biener wrote:
On Mon, Sep 6, 2021 at 1:08 PM Richard Earnshaw
wrote:
On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote:
On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote:
GCC was recently changed to prevent simplify_subreg from simplifying
a
Hi Segher,
I think the current documentation is sufficient. During compilation, GCC's
combine pass will often substitute a register with an expression defining
it's value, and then attempt to simplify it. As you point out, this often
produces
(temporary intermediate) expressions with poorly def
On 8/26/21 13:04, Richard Biener wrote:
Yes, and that flag_complex_method is initialized via the langhook
mentioned, for example
c-family/c-opts.c has
/* Initialize options structure OPTS. */
void
c_common_init_options_struct (struct gcc_options *opts)
{
opts->x_flag_exceptions = c_dialect_c
On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *opts, struct
> gcc_options *opts_set,
>= (opts->x_flag_unroll_loops
> || opts->x_flag_peel_loops
> || opts->x
On Mon, Sep 6, 2021 at 1:23 PM Richard Earnshaw
wrote:
>
>
>
> On 06/09/2021 12:13, Richard Biener wrote:
> > On Mon, Sep 6, 2021 at 1:08 PM Richard Earnshaw
> > wrote:
> >>
> >>
> >>
> >> On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote:
> >>> On Mon, Sep 6, 2021 at 12:40 PM Richard Ear
This patch adds type checking for static local vector variable in
C++ template, both AArch64 SVE and RISCV RVV are of sizeless type
and thay all have this issue.
2021-08-06 wangpc
gcc/cp/ChangeLog
* pt.c (tsubst_decl): Add type checking.
gcc/testsuite/ChangeLog
* g++.target/
On Mon, Sep 06, 2021 at 10:05:00AM +0800, Hongtao Liu wrote:
> @@ -1076,9 +1076,11 @@ systems where @code{__float128} is supported.
> The @code{_Float32}
> type is supported on all systems supporting IEEE binary32; the
> @code{_Float64} and @code{_Float32x} types are supported on all systems
>
On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
> > --- a/gcc/opts.c
> > +++ b/gcc/opts.c
> > @@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *opts, struct
> > gcc_options *opts_set,
> >= (opts->x_flag_unroll_
On Mon, Sep 6, 2021 at 1:15 PM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 07:15:41PM +0800, Hongtao Liu wrote:
> > > So what about finish_options then?
> > > default_options_optimization has only a single caller that then calls
> > > read_cmdline_options and then finish_options.
> > in finis
Hi,
On Tuesday, 20 July 2021 22:22:02 CEST Jason Merrill wrote:
> The C++ front end already uses PAREN_EXPR in templates to indicate
> parenthesized initializers in cases where that matters for
> decltype(auto). It should be fine to use it for both that and
> __builtin_assoc_barrier, but you prob
On Mon, Sep 06, 2021 at 02:16:58PM +0200, Richard Biener wrote:
> On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote:
> >
> > On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
> > > --- a/gcc/opts.c
> > > +++ b/gcc/opts.c
> > > @@ -1323,6 +1323,14 @@ finish_options (struct gcc_options
On Mon, Sep 06, 2021 at 02:18:59PM +0200, Richard Biener wrote:
> On Mon, Sep 6, 2021 at 1:15 PM Jakub Jelinek wrote:
> >
> > On Mon, Sep 06, 2021 at 07:15:41PM +0800, Hongtao Liu wrote:
> > > > So what about finish_options then?
> > > > default_options_optimization has only a single caller that t
On Sun, Sep 5, 2021 at 10:34 PM Hongtao Liu wrote:
>
> On Sun, Sep 5, 2021 at 5:56 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > Enable FMA in scalar/vector unsigned SI to SF expanders.
> >
> > gcc/
> >
> > PR target/85819
> > * config/i386/i386-expand.c (ix86_expand_convert_uns_sis
On Mon, 6 Sep 2021, Matthias Kretz wrote:
> Hi,
>
> On Tuesday, 20 July 2021 22:22:02 CEST Jason Merrill wrote:
> > The C++ front end already uses PAREN_EXPR in templates to indicate
> > parenthesized initializers in cases where that matters for
> > decltype(auto). It should be fine to use it fo
On Mon, Sep 6, 2021 at 2:30 PM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 02:18:59PM +0200, Richard Biener wrote:
> > On Mon, Sep 6, 2021 at 1:15 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Sep 06, 2021 at 07:15:41PM +0800, Hongtao Liu wrote:
> > > > > So what about finish_options then?
> >
On Monday, 6 September 2021 14:40:31 CEST Richard Biener wrote:
> I'll note that currently a + PAREN_EXPR (b * c) is for example
> also not contracted to PAREN_EXPR (FMA (PAREN_EXPR (a), b, c))
> even though technically FP contraction is not association. But
> that's an implementation detail that
On Mon, 6 Sep 2021, Matthias Kretz wrote:
> On Monday, 6 September 2021 14:40:31 CEST Richard Biener wrote:
> > I'll note that currently a + PAREN_EXPR (b * c) is for example
> > also not contracted to PAREN_EXPR (FMA (PAREN_EXPR (a), b, c))
> > even though technically FP contraction is not associ
Jakub Jelinek writes:
> On Mon, Sep 06, 2021 at 12:49:18PM +0300, Serge Belyshev wrote:
> * gcc_update: derive human readable name for HEAD using git describe
>
> After : start with upper case, ^^^ Derive
>
> like "git gcc-descr" with short commit hash. Drop "revision" from
> gcc/RE
Ping?
[PATCH] Add --enable-first-stage-cross configure option
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575318.html
> Add --enable-first-stage-cross configure option
>
> Build static-only, C-only compiler that is sufficient to cross compile
> glibc. This option disables various runtim
On 13.08.21 16:37, Tobias Burnus wrote:
Update the OpenMP section again, now that Jakub has added the 'masked'
construct.
Comments?
Jakub did comment on IRC that it probably makes sense to do less
frequent commits.
Thus, I waited a while and now have an update list. Besides 'masked' it
now men
On Mon, Sep 06, 2021 at 03:20:44PM +0200, Tobias Burnus wrote:
> On 13.08.21 16:37, Tobias Burnus wrote:
>
> > Update the OpenMP section again, now that Jakub has added the 'masked'
> > construct.
> > Comments?
>
> Jakub did comment on IRC that it probably makes sense to do less
> frequent commit
Hi!
On Mon, Sep 06, 2021 at 12:32:13PM +0100, Roger Sayle wrote:
> I think the current documentation is sufficient. During compilation, GCC's
> combine pass will often substitute a register with an expression defining
> it's value, and then attempt to simplify it. As you point out, this often
>
On Monday, 6 September 2021 14:59:27 CEST Richard Biener wrote:
> On Mon, 6 Sep 2021, Matthias Kretz wrote:
> > On Monday, 6 September 2021 14:40:31 CEST Richard Biener wrote:
> > > I'll note that currently a + PAREN_EXPR (b * c) is for example
> > > also not contracted to PAREN_EXPR (FMA (PAREN_EX
Hi,
this patch adds support for the 'seq_cst' memory order clause on the
'flush' directive which was introduced in OpenMP 5.1 (p.275ff of the
OpenMP 5.1 Specification):
"If neither memory-order-clause nor a list appears on the flush
construct then the behavior is as if memory-order-clause is seq
On Sun, 5 Sep 2021, Sandra Loosemore wrote:
> Unless the aarch64 maintainers think it is a bug that __float128 is not
> supported, I think the right solution here is the one I was thinking of
> previously, to fix the Fortran front end to tie the C_FLOAT128 kind to
> _Float128 rather than __float12
On Mon, 6 Sep 2021, liuhongt via Gcc-patches wrote:
> Hi:
> As discussed in [1], most of (currently unopposed) targets want
> auto-vectorization at O2, and IMHO now would be a good time to enable O2
> vectorization for GCC trunk, so it would leave enough time to expose
> related issues and fix t
Hi Jakub, hi all,
as the issue came up from time to time, I thought it
makes sense to add an implementation status.
I settled on putting it into libgomp.texi instead of
a webpage or another location.
The 5.1 section should be fine – except for additional
items. OpenMP 5.0 has stub wordings and
Copy'n'paste error of mine when I documented -foffload(-options)= in r12-1871.
Committed as obvious in r12-3371.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heuru
On 9/3/2021 1:32 AM, YunQiang Su wrote:
Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
assembler is mips1 by default,
gcc is fpxx by default.
To assemble the output of gcc -S, we have to pass -mips2
to assembler.
The same situation is f
On 9/5/2021 3:39 PM, Roger Sayle wrote:
As diagnosed with Jakub and Richard in the analysis of PR 102134, the
current implementation of wi::clz has incorrect/inconsistent behaviour.
As mentioned by Richard in comment #7, clz should (always) return zero
for negative values, but the current impl
On 8/18/2021 2:38 AM, Martin Liška wrote:
On 6/23/21 3:15 PM, Martin Liška wrote:
On 6/23/21 2:38 PM, Jan Hubicka wrote:
Is there reason to prevent the inlining once instrumentation is done?
No ;)
I think you can just block it for early inliner.
Sure. Do you have a handy predicate func
On 19.08.21 04:57, Sandra Loosemore wrote:
This is a follow-up to commit fef67987cf502fe322e92ddce22eea7ac46b4d75:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fef67987cf502fe322e92ddce22eea7ac46b4d75
I realized last week that having multilib-specific versions of
ISO_Fortran_binding.h (genera
PING.
> Gesendet: Montag, 30. August 2021 um 23:40 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/101327 - ICE in find_array_element, at
> fortran/expr.c:1355
>
> There was an issue when trying to use an element from an array constructor
> which was a b
Hi!
On Mon, Sep 06, 2021 at 04:59:27PM +0800, Xionghu Luo wrote:
> On 2021/9/4 05:44, Segher Boessenkool wrote:
> >>+/* { dg-final { scan-assembler-not {\mbl fmod\M} } } */
> >>+/* { dg-final { scan-assembler-not {\mbl fmodf\M} } } */
> >>+/* { dg-final { scan-assembler-not {\mbl remainder\M} } }
Hi!
On Mon, Sep 06, 2021 at 02:10:58PM +0800, HAO CHEN GUI wrote:
> The patch optimized expansion for long long or double vec_reve builtin.
>
> Bootstrapped and tested on powerpc64le-linux with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
In the future, p
Hi!
On Wed, Jul 28, 2021 at 10:59:50AM +0800, Kewen.Lin wrote:
> >> +/* As a visitor function for each statement cost entry handled in
> >> + function add_stmt_cost, gather some information and update its
> >> + relevant fields in target cost accordingly. */
> >
> > I got lost trying to pars
On 30.08.21 23:40, Harald Anlauf via Fortran wrote:
There was an issue when trying to use an element from an array constructor
which was a broken in a way probably only Gerhard could conceive.
We hit an assert that can be replaced by more robust code.
Patch is basically Steve's.
Regtested on x86
On Mon, Sep 6, 2021 at 8:35 PM H.J. Lu wrote:
>
> On Sun, Sep 5, 2021 at 10:34 PM Hongtao Liu wrote:
> >
> > On Sun, Sep 5, 2021 at 5:56 AM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > Enable FMA in scalar/vector unsigned SI to SF expanders.
> > >
> > > gcc/
> > >
> > > PR target/85819
On Mon, Sep 6, 2021 at 8:13 PM Jakub Jelinek wrote:
>
> On Mon, Sep 06, 2021 at 10:05:00AM +0800, Hongtao Liu wrote:
>
> > @@ -1076,9 +1076,11 @@ systems where @code{__float128} is supported.
> > The @code{_Float32}
> > type is supported on all systems supporting IEEE binary32; the
> > @code{_Fl
On Tue, Sep 7, 2021 at 12:37 AM Joseph Myers wrote:
>
> On Mon, 6 Sep 2021, liuhongt via Gcc-patches wrote:
>
> > Hi:
> > As discussed in [1], most of (currently unopposed) targets want
> > auto-vectorization at O2, and IMHO now would be a good time to enable O2
> > vectorization for GCC trunk,
88 matches
Mail list logo
