On Tue, 8 Nov 2022, Qing Zhao wrote:
> The name of the utility routine "array_at_struct_end_p" is misleading
> and should be changed to a new name that more accurately reflects its
> real meaning.
>
> The routine "array_at_struct_end_p" is used to check whether an array
> reference is to an array
> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64
> cfarm machines which I used for testing don't have gnat installed, do
Jiufu Guo via Gcc-patches writes:
> Richard Biener writes:
>
>> On Tue, 1 Nov 2022, Jiufu Guo wrote:
>>
>>> Segher Boessenkool writes:
>>>
>>> > On Mon, Oct 31, 2022 at 04:13:38PM -0600, Jeff Law wrote:
>>> >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
>>> >> >We know that for struct
On Wed, Nov 9, 2022 at 4:29 AM Sinan via Gcc-patches
wrote:
>
> add a missing variable name.
OK.
On Wed, Nov 9, 2022 at 1:09 AM Sam James via Gcc-patches
wrote:
>
>
>
> > On 9 Nov 2022, at 00:00, Joseph Myers wrote:
> >
> > On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> >
> >> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
> >> even for snapshots? Pretty please? :)
> >
> >
There is a paragraph in the explanation information for the compile
parameter '-fno-fp-int-builtin-inexact' in the gcc.pdf document:
"Do not allow the built-in functions ceil, floor, round and trunc,
and their float and long double variants,
to generate code that raises the “inexact”
On Tue, Nov 8, 2022 at 9:02 PM Michael Collison wrote:
>
> This patches transforms (cond (and (x , 0x1) == 0), y, (z op y)) into
> (-(and (x , 0x1)) & z ) op y, where op is a '^' or a '|'. It also
> transforms (cond (and (x , 0x1) != 0), (z op y), y ) into (-(and (x ,
> 0x1)) & z ) op y.
>
> Match
LGTM.
Thanks!
在 2022/11/9 下午3:26, Xi Ruoyao 写道:
Signed overflow is an undefined behavior, so we need to prevent it from
happening, instead of "checking" the result.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Avoid signed overflow.
---
v1 -> v
Signed overflow is an undefined behavior, so we need to prevent it from
happening, instead of "checking" the result.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Avoid signed overflow.
---
v1 -> v2: break instead of continue if the inc/dec will ove
Use standard name so __builtin_rint{,f} can be expanded to one
instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.md (frint_): Rename to ..
(rint2): .. this.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/frint.c: New test.
---
gcc/config/loongarch/loongarch.md
On LoongArch, flogb instructions extract the exponent of a non-negative
floating point value, but produces NaN for negative values. So we need
to add a fabs instruction when we expand logb.
gcc/ChangeLog:
* config/loongarch/loongarch.md (UNSPEC_FLOGB): New unspec.
(type): Add flo
This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with
-fno-math-errno.
IMODE is added because we can't hard code SI for operand 2: fscaleb.d
instruction always take the high half of both source registers into
account. See my_ldexp_long in the test case.
gcc/ChangeLog:
This allows to optimize the following builtins if -fno-math-errno:
- __builtin_lrint{,f}
- __builtin_lfloor{,f}
- __builtin_lceil{,f}
Inspired by
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html.
ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32. If we
simply use
These patches allow to expand the following builtins to floating point
instructions for LoongArch:
- __builtin_rint{,f}
- __builtin_{l,ll}rint{,f}
- __builtin_{l,ll}floor{,f}
- __builtin_{l,ll}ceil{,f}
- __builtin_scalb{n,ln}{,f}
- __builtin_logb{,f}
Bootstrapped and regtested on loongarch64-linu
Hi all,
As Hongtao said, the fail on pentiumpro is caused by missing ISA check
since we are using emit_insn () through new builtins and it won't check
if the TARGET matches. Previously, the builtin in middle-end will check
that.
On pentiumpro, we won't have anything that supports any prefetch so
Now that the generic parts of the binary operators have been
abstracted, implementing MINUS_EXPR is a cinch.
The op[12]_range entries will be submitted as a follow-up.
gcc/ChangeLog:
* range-op-float.cc (class foperator_minus): New.
(floating_op_table::floating_op_table): Add MIN
The PLUS_EXPR was always meant to be a template for further
development, since most of the binary operators will share a similar
structure. This patch abstracts out the common bits into the default
definition for range_operator_float::fold_range() and provides an
rv_fold() to be implemented by the
Hi Richi and Eric,
Thanks for your reviews and comments!
on 2022/11/8 18:37, Eric Botcazou wrote:
>> It looks reasonable - OK if the others CCed have no comments.
>
> My only comment is that it needs to be tested with languages enabling -fnon-
> call-exceptions by default (Ada & Go), if not alre
This patch fixes the oversight.
Tested on x86-64 Linux.
Pushed.
On Wed, Nov 9, 2022 at 12:05 AM Aldy Hernandez wrote:
>
> Sigh, one more thing.
>
> There are further possibilities for a NAN result, even if the operands
> are !NAN and the result from frange_arithmetic is free of NANs.
> Adding d
On Tue, 08 Nov 2022 20:43:20 PST (-0800), pins...@gmail.com wrote:
On Tue, Nov 8, 2022 at 7:16 PM Palmer Dabbelt wrote:
On Tue, 08 Nov 2022 18:57:26 PST (-0800), jeffreya...@gmail.com wrote:
>
> On 11/8/22 12:54, Philipp Tomsich wrote:
>> The BSWAP operation is not handled in rtx_costs. Add it
On Tue, Nov 8, 2022 at 7:16 PM Palmer Dabbelt wrote:
>
> On Tue, 08 Nov 2022 18:57:26 PST (-0800), jeffreya...@gmail.com wrote:
> >
> > On 11/8/22 12:54, Philipp Tomsich wrote:
> >> The BSWAP operation is not handled in rtx_costs. Add it.
> >>
> >> With Zbb, BSWAP for XLEN is a single instruction;
On Tue, 08 Nov 2022 19:26:01 PST (-0800), gcc-patches@gcc.gnu.org wrote:
loading constant 0x739290001LL in rv32 can be done with three instructions
output:
li a1, 7
lui a1, 234128
addi a1, a1, 1
Probably more useful to load the constant into two different registers?
The point is the same, tho
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604415.html
BR,
Jeff(Jiufu)
Jiufu Guo writes:
> Hi,
>
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
>
> For constant C:
> if '(c & 0x80008000ULL) == 0x8000ULL' or say:
> 32(0
add a missing variable name.
0001-doc-FixDocTypo.patch
Description: Binary data
loading constant 0x739290001LL in rv32 can be done with three instructions
output:
li a1, 7
lui a1, 234128
addi a1, a1, 1
Similarly, loading 0x839290001LL in rv32 can be done within three instructions
expected output:
li a1, 8
lui a1, 234128
addi a1, a1, 1
However, riscv_build_integer does not hand
Hi,
I would like to have a ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html
BR,
Jeff(Jiufu)
Jiufu Guo writes:
> Hi,
>
> There is a functionality as const_anchor in cse.cc. This const_anchor
> supports to generate new constants through adding small gap/of
On Tue, 08 Nov 2022 18:57:26 PST (-0800), jeffreya...@gmail.com wrote:
On 11/8/22 12:54, Philipp Tomsich wrote:
The BSWAP operation is not handled in rtx_costs. Add it.
With Zbb, BSWAP for XLEN is a single instruction; for smaller modes,
it will expand into two.
gcc/ChangeLog:
* con
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
BR,
Jeff (Jiufu)
Jiufu Guo via Gcc-patches writes:
> Gentle ping:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
>
> BR,
> Jeff (Jiufu)
>
> Jiufu Guo via Gcc-patches writes:
>
>> Pi
These extensions were recently frozen [1]. As per Andrew's post [2]
we're meant to ignore these in software, this just adds them to the list
of allowed extensions and otherwise ignores them. I added these under
SPEC_CLASS_NONE even though the PDF lists them as 20190614 because it
seems pointless
On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muell...@vrull.eu wrote:
On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt wrote:
The docs say we take ISA strings, but that's never really been the case:
at a bare minimum we've required lower case strings, but there's
generally been some subtle
On 11/8/22 12:54, Philipp Tomsich wrote:
The BSWAP operation is not handled in rtx_costs. Add it.
With Zbb, BSWAP for XLEN is a single instruction; for smaller modes,
it will expand into two.
gcc/ChangeLog:
* config/riscv/riscv.c (rtx_costs): Add BSWAP.
OK.
Jeff
On Tue, Nov 8, 2022 at 6:07 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, Nov 04, 2022 at 03:46:32PM +0800, Haochen Jiang via Gcc-patches wrote:
> > We will take back the patches which add a new parameter on original
> > builtin_prefetch and implement instruction prefetch on that.
> >
> > Al
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such values.
Signed-off-by: Ben Boeckel
---
li
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the out
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
libcpp/
* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
* internal.h: Add prototype for `_cpp_valid_utf8_s
Hi,
This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ensure that `import
some_module;` can
On Wed, 2022-11-09 at 01:52 +, Joseph Myers wrote:
> On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
>
> > I'm wondering if running xz -T0 on different machines (with different
> > core numbers) may produce different compressed data. The difference can
> > cause trouble distributing chec
On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
> I'm wondering if running xz -T0 on different machines (with different
> core numbers) may produce different compressed data. The difference can
> cause trouble distributing checksums.
gcc_release definitely doesn't use any options to make th
> Although ix86_small_unroll_insns is coming from issue_rate, it's tuned
> for codesize.
> Make it exact as issue_rate and using factor * issue_width /
> loop->ninsns may increase code size too much.
> So I prefer to add those 2 parameters to the cost table for core
> tunings instead of 1.
Yes, he
On Tue, Nov 8, 2022 at 9:17 AM liuhongt wrote:
>
> Memory attribute auto detection will check operand 2 for type sselog,
> and check operand 1 for type sselog1. For below 2 insns, there's no
> operand 2. Change type to sselog1.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for
> On 9 Nov 2022, at 00:00, Joseph Myers wrote:
>
> On Tue, 8 Nov 2022, Sam James via Gcc wrote:
>
>> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
>> even for snapshots? Pretty please? :)
>
> I think we want snapshots to come out weekly even if the compiler or
> documentat
Optimize the common case of a SImode min/max against a constant
that is safe both for sign- and zero-extension.
E.g., consider the case
int f(unsigned int* a)
{
const int C = 1000;
return *a * 3 > C ? C : *a * 3;
}
where the constant C will yield the same result in DImode whether
sign
On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899)
> even for snapshots? Pretty please? :)
I think we want snapshots to come out weekly even if the compiler or
documentation build fails, which makes anything involving a build as part
On Mon, 7 Nov 2022 at 14:55, Alexander Monakov wrote:
>
>
>
> On Sat, 5 Nov 2022, Philipp Tomsich wrote:
>
> > Alexander,
> >
> > I had missed your comment until now.
>
> Please make sure to read replies from Jeff and Palmer as well (their responses
> went to gcc-patches with empty Cc list):
> htt
On 11/8/22 04:42, Jakub Jelinek wrote:
Hi!
A comment in D2552R1:
"The only questionable (but still conforming) case we found was
[[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said
that the
carries_dependency attribute is not supported, but did not specifically call
Sigh, one more thing.
There are further possibilities for a NAN result, even if the operands
are !NAN and the result from frange_arithmetic is free of NANs.
Adding different signed infinities.
For example, [-INF,+INF] + [-INF,+INF] has the possibility of adding
-INF and +INF, which is a NAN. Sin
In r12-3094-ge82e0f149b0aba I added the assumption that
POINTER_PLUS_EXPR of non-NULL is non-NULL (for PR analyzer/101962).
Whilst working on another bug, I noticed that this only works
when the LHS is known to be non-NULL via
region_model::eval_condition_without_cm, but not when it's known throug
Le 08/11/2022 à 21:31, Harald Anlauf a écrit :
Hi Mikael,
Am 08.11.22 um 11:32 schrieb Mikael Morin:
this is mostly good.
There is one last corner case that is not properly handled:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 63515b9072a..94988b8690e 100644
--- a/
I realize this is a feature with a somewhat niche use-case, but I'd really
like to have it in gcc 13, if possible. Any feedback is appreciated.
On 2022-10-17 16:44, J.W. Jagersma wrote:
> Recently I tried to set a function's target attribute conditionally
> based on template parameters, eg.:
>
>
Optimize the common case of a SImode min/max against a constant
that is safe both for sign- and zero-extension.
E.g., consider the case
int f(unsigned int* a)
{
const int C = 1000;
return *a * 3 > C ? C : *a * 3;
}
where the constant C will yield the same result in DImode whether
sign
gcc/ChangeLog:
* config/riscv/predicates.md (shifted_const_arith_operand):
(uimm_extra_bit_operand):
* config/riscv/riscv.md (*branch_shiftedarith_equals_zero):
(*branch_shiftedmask_equals_zero):
gcc/testsuite/ChangeLog:
* gcc.target/riscv/branch-1.c: New
Hi Mikael,
Am 08.11.22 um 11:32 schrieb Mikael Morin:
this is mostly good.
There is one last corner case that is not properly handled:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 63515b9072a..94988b8690e 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/tran
Hi!
On 2017-06-09T16:24:30+0200, Tom de Vries wrote:
> The patch defines an effective target stack_size, which is used in
> individual test-cases to add -DSTACK_SIZE= [...]
> gccint.info (edited for long lines):
> ...
> 7.2.3.12 Other attributes
> .
>
> 'stack_size'
>
LGTM.
-- Jeff J.
On Tue, Nov 8, 2022 at 1:31 PM Thomas Schwinge
wrote:
> ..., not just '#if defined(__CYGWIN__)'. (Exception: 'clog10l' which
> currently
> indeed is for Cygwin only.)
>
> This completes 2017-07-05 commit be3ca3947402827aa52709e677369bc7ad30aa1d
> "Fixed warnings for some long
On Tue, Nov 8, 2022 at 12:02 PM Michael Collison wrote:
>
> This patches transforms (cond (and (x , 0x1) == 0), y, (z op y)) into
> (-(and (x , 0x1)) & z ) op y, where op is a '^' or a '|'. It also
> transforms (cond (and (x , 0x1) != 0), (z op y), y ) into (-(and (x ,
> 0x1)) & z ) op y.
>
> Matc
As long as the SImode operand is not a partial subreg, we can use a
bseti without postprocessing to or in a bit, as the middle end is
smart enough to stay away from the signbit.
gcc/ChangeLog:
* config/riscv/bitmanip.md (*bsetidisi): New pattern.
gcc/testsuite/ChangeLog:
* gcc.t
This patches transforms (cond (and (x , 0x1) == 0), y, (z op y)) into
(-(and (x , 0x1)) & z ) op y, where op is a '^' or a '|'. It also
transforms (cond (and (x , 0x1) != 0), (z op y), y ) into (-(and (x ,
0x1)) & z ) op y.
Matching this patterns allows GCC to generate branchless code for one
gcc/ChangeLog:
* config/riscv/bitmanip.md: Handle corner-cases for combine
when chaining slli(.uw)? + addw
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zba-shNadd-04.c: New test.
---
gcc/config/riscv/bitmanip.md | 49 +++
gcc/config/risc
When using strength-reduction, we will reduce a multiplication to a
sequence of shifts and adds. If this is performed with 32-bit types
and followed by a division, the lack of w-form sh[123]add will make
combination impossible and lead to a slli + addw being generated.
Split the sequence with the
Consider creating a polarity-reversed mask from a set-bit (i.e., if
the bit is set, produce all-ones; otherwise: all-zeros). Using Zbb,
this can be expressed as bexti, followed by an addi of minus-one. To
enable the combiner to discover this opportunity, we need to split the
canonical expression
If we are testing a register or a paradoxical subreg (i.e. anything that is not
a partial subreg) for equality/non-equality with zero, we can generate a branch
that compares against $zero. This will work for QI, HI, SI and DImode, so we
enable this for ANYI.
2020-08-30 gcc/ChangeLog:
*
If-conversion is turning '(a >= 0) ? b : 0' into a branchless sequence
not a5,a0
sraia5,a5,63
and a0,a1,a5
missing the opportunity to combine the NOT and AND into an ANDN.
This adds a define_split to help the combiner reassociate the NOT with
the AND.
gcc/Chan
The strength-reduction implementation in expmed.c will assess the
profitability of using shift-and-add using a RTL expression that wraps
a MULT (with a power-of-2) in a PLUS. Unless the RISC-V rtx_costs
function recognizes this as expressing a sh[123]add instruction, we
will return an inflated cos
The BSWAP operation is not handled in rtx_costs. Add it.
With Zbb, BSWAP for XLEN is a single instruction; for smaller modes,
it will expand into two.
gcc/ChangeLog:
* config/riscv/riscv.c (rtx_costs): Add BSWAP.
---
gcc/config/riscv/riscv.cc | 10 ++
1 file changed, 10 insert
> On 8 Nov 2022, at 13:55, Martin Liška wrote:
>
> Hi.
>
> Tomorrow in the morning (UTC time), I'm going to migrate the documentation
> to Sphinx. The final version of the branch can be seen here:
>
> $ git fetch origin refs/users/marxin/heads/sphinx-final
> $ git co FETCH_HEAD
>
> URL: http
..., not just '#if defined(__CYGWIN__)'. (Exception: 'clog10l' which currently
indeed is for Cygwin only.)
This completes 2017-07-05 commit be3ca3947402827aa52709e677369bc7ad30aa1d
"Fixed warnings for some long double complex methods" after Aditya Upadhyay's
work on importing "Long double complex
PR92999 is a case where the VFP calling convention does not allocate
enough FP registers for a homogenous aggregate containing FP16 values.
I believe this is the complete fix but would appreciate another set of
eyes on this.
Could I get a hand with a regression test run on an armhf environment
whi
On Tue, Nov 8, 2022 at 10:11 AM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote:
> > On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > > > As suggested up
On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote:
> On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > > As suggested upthread, I have also adjusted update_nan_sign() to drop
> > > the NAN
And use that to speed up the libgcc unwinder.
* gcc/debug.h (dwarf_reg_sizes_constant): Declare.
* gcc/dwarf2cfi.cc (dwarf_reg_sizes_constant): New function.
* gcc/c-family/c-cppbuiltin.c
(__LIBGCC_DWARF_REG_SIZES_CONSTANT__): Define if constant is
known.
l
The parameters fs->data_align and fs->code_align always have fixed
values for a particular target in GCC-generated code. Specialize
execute_cfa_program for these values, to avoid multiplications.
gcc/
* c-family/c-cppbuiltin.c (c_cpp_builtins): Define
__LIBGCC_DWARF_CIE_DATA_ALIG
This series makes some further unwinder improvements. Unfortunately,
not many targets define __LIBGCC_DWARF_REG_SIZES_CONSTANT__; x86-64
does, and it makes uw_install_context_1 quite a bit faster because GCC
no longer has to emit generic memcpy code for it. In general, it may be
worthwhile to rep
The sizes are compile-time constants. Create a vector with them,
so that they can be inspected at compile time.
* gcc/dwarf2cfi.cc (init_return_column_size): Remove.
(init_one_dwarf_reg_size): Adjust.
(generate_dwarf_reg_sizes): New function. Extracted
from expand
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/18_support/new_nothrow.cc: Add missing noexcept
to operator delete replacements.
* testsuite/20_util/any/cons/92156.cc: Disable
-Winit-list-lifetime warnings from instantiating inva
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix some problems noticed with -Wsystem-headers.
libstdc++-v3/ChangeLog:
* include/bits/stl_tempbuf.h (_Temporary_buffer): Disable
warnings about get_temporary_buffer being deprecated.
* include/ext/functional (mem_fun1, mem
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
This reduces the abstraction penalty for allocator support in
unoptimized code. Constructing and using allocators in containers calls
many one-line (or completely empty) inline functions. Those can all be
inlined to reduce code size and function
On Mon, 7 Nov 2022 at 17:00, Jonathan Wakely wrote:
>
> On Thu, 6 Oct 2022 at 20:03, Charles-Francois Natali via Libstdc++
> wrote:
> >
> > `basic_filebuf::xsputn` would bypass the buffer when passed a chunk of
> > size 1024 and above, seemingly as an optimisation.
> >
> > This can have a signific
On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > As suggested upthread, I have also adjusted update_nan_sign() to drop
> > the NAN sign to VARYING if both operands are NAN. As an optimization
> > I keep the
On Thu, 20 Oct 2022 at 01:06, Will Hawkins wrote:
>
> Sorry for the delay. Tested on x86-64 Linux.
>
> -->8--
>
> After consultation with Jonathan, it seemed like a good idea to create a
> single function that performed one-allocation string concatenation that
> could be used by various different v
Ping.
> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 31, 2022 11:35 AM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com
> Subject: RE: [PATCH 1/4]middle-end Support not decomposing specific
> divisions during vectorization.
>
> >
> > Th
On Tue, Nov 8, 2022 at 5:37 PM Surya Kumari Jangala
wrote:
>
> Hi Richard,
>
> On 21/09/22 1:03 pm, Richard Biener wrote:
> > On Tue, Sep 20, 2022 at 9:18 AM Surya Kumari Jangala via Gcc-patches
> > wrote:
> >>
> >> Hi Jeff, Richard,
> >> Thank you for reviewing the patch!
> >> I have committed t
On Tue, Nov 8, 2022 at 8:46 AM Andreas Schwab via Gdb-patches
wrote:
>
> On Nov 08 2022, apinski--- via Gcc-patches wrote:
>
> > diff --git a/configure b/configure
> > index 7bcb894d1fe..9ee7a1a3abe 100755
> > --- a/configure
> > +++ b/configure
> > @@ -769,6 +769,7 @@ infodir
> > docdir
> > old
On Nov 08 2022, apinski--- via Gcc-patches wrote:
> diff --git a/configure b/configure
> index 7bcb894d1fe..9ee7a1a3abe 100755
> --- a/configure
> +++ b/configure
> @@ -769,6 +769,7 @@ infodir
> docdir
> oldincludedir
> includedir
> +runstatedir
> localstatedir
> sharedstatedir
> sysconfdir
Hi Richard,
On 21/09/22 1:03 pm, Richard Biener wrote:
> On Tue, Sep 20, 2022 at 9:18 AM Surya Kumari Jangala via Gcc-patches
> wrote:
>>
>> Hi Jeff, Richard,
>> Thank you for reviewing the patch!
>> I have committed the patch to the gcc repo.
>> Can I backport this patch to prior versions of gcc
From: Andrew Pinski
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR with the toplevel
directory just like how it is done fo
At 2022-11-08 22:58:34, "Richard Biener" wrote:
>On Sat, Nov 5, 2022 at 10:03 AM Zhongyunde via Gcc-patches
> wrote:
>>
>>
>> > -Original Message-
>> > From: Andrew Pinski [mailto:pins...@gcc.gnu.org]
>> > Sent: Saturday, November 5, 2022 2:34 PM
>> > To: Zhongyunde
>> > Cc: hongtao@
The name of the utility routine "array_at_struct_end_p" is misleading
and should be changed to a new name that more accurately reflects its
real meaning.
The routine "array_at_struct_end_p" is used to check whether an array
reference is to an array whose actual size might be larger than its
upper
Hello
These additional patches were pushed onto the devel/omp/gcc-12 branch to
fix various issues with the SIMD math library:
ecf1603b7ad amdgcn: Fix expansion of GCN_BUILTIN_LDEXPV builtin
6c40e3f5daa amdgcn: Various fixes for SIMD math library
8e6c5b18e10 amdgcn: Fixed intermittent failure i
Hello
This patch fixes a bug in the expansion of GCN_BUILTIN_LDEXPV. As this
is a double-precision operation, the first argument should be expanded
as a V64DF expression (instead of V64SF).
Committed to trunk as obvious.
KwokFrom cb0a2b1f28cf0c231bf38fcd02c40689739df7bb Mon Sep 17 00:00:00 2
On Tue, Nov 8, 2022 at 3:25 PM Aldy Hernandez wrote:
>
> We have some code in range-ops that sets better maybe nonzero bits for
> TRUNC_DIV_EXPR by a power of 2 than CCP does, by just shifting the
> mask. I'd like to offload this functionality into the CCP mask
> tracking code, which already does
On Sat, Nov 5, 2022 at 10:03 AM Zhongyunde via Gcc-patches
wrote:
>
>
> > -Original Message-
> > From: Andrew Pinski [mailto:pins...@gcc.gnu.org]
> > Sent: Saturday, November 5, 2022 2:34 PM
> > To: Zhongyunde
> > Cc: hongtao@intel.com; gcc-patches@gcc.gnu.org; Zhangwen(Esan)
> > ; We
On 26/10/2022 09:49, Andrea Corallo via Gcc-patches wrote:
Richard Earnshaw writes:
On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote:
-Original Message-
From: Andrea Corallo
Sent: Tuesday, September 27, 2022 11:06 AM
To: Kyrylo Tkachov
Cc: Andrea Corallo via Gcc-patche
This patch serie include two changes:
1. Change the name of array_at_struct_end_p to array_ref_flexible_size_p.
2. Add a new warning option -Wstrict-flex-arrays and at the same time
keep -Warray-bounds unchanged from -fstrict-flex-arrays.
The new warning -Wstrict-flex-arrays is implemented a
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
On 08/11/2022 14:35, Kwok Cheung Yeung wrote:
Hello
This patch adds three extra builtins for the vectorized forms of the
abs, floorf and floor math functions, which are implemented by native
GCN instructions. I have also added a test to check that they generate
the expected assembler instruct
Hi!
A comment in D2552R1:
"The only questionable (but still conforming) case we found was
[[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said
that the
carries_dependency attribute is not supported, but did not specifically call
out the syntax error
in the argument cla
On Fri, Nov 4, 2022 at 7:44 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> On Fri, 4 Nov 2022 at 05:36, Hongyu Wang via Gcc-patches
> wrote:
> >
> > Hi,
> >
> > This is a follow-up patch for PR98167
> >
> > The sequence
> > c1 = VEC_PERM_EXPR (a, a, mask)
> > c2 = VEC_PERM_EXPR (b, b
Hello
This patch adds three extra builtins for the vectorized forms of the
abs, floorf and floor math functions, which are implemented by native
GCN instructions. I have also added a test to check that they generate
the expected assembler instructions.
Okay for trunk?
Thanks
KwokFrom 37f49
We have some code in range-ops that sets better maybe nonzero bits for
TRUNC_DIV_EXPR by a power of 2 than CCP does, by just shifting the
mask. I'd like to offload this functionality into the CCP mask
tracking code, which already does the right thing for right shifts.
The testcase for this change
On Thu, Nov 3, 2022 at 9:07 PM Lewis Hyatt wrote:
>
> On Fri, Oct 28, 2022 at 10:28:21AM +0200, Richard Biener wrote:
> > Yes, the idea was also to free up memory but then that part never
> > really materialized - the idea was to always run free-lang-data, not
> > just when later outputting LTO by
1 - 100 of 169 matches
Mail list logo
