When we split
(insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
(mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct
SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84
{*movdi_internal}
(expr_list:REG_EH_REGION (const_int -11 [0xfff5])
int
The behavior of non-zero unused bits in xvpermi.q instruction's
third operand is undefined on LoongArch, according to our
discussion (https://github.com/llvm/llvm-project/pull/83540),
we think that keeping original insn operand as unmodified
state is better solution.
This patch partially reverts 7
Tested with GDB 14.1 on x86_64-linux. I'll backport this too.
-- >8 --
A recent GDB change causes this test to fail due to missing RTTI for the
custom_cast type. This is presumably because the custom_cat type was
defined as a local class, so has no linkage. Moving it to local scope
seems to fix t
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug.xml: Improve docs on debug builds and
using ASan. Mention _GLIBCXX_ASSERTIONS. Reorder sections to put
the most relevant ones first.
* doc/xml/manual/using.xml: Add comma.
* doc/html/
On Thu, 7 Mar 2024 at 12:07, Jonathan Wakely wrote:
>
> Any objection to this update to make the docs reflect reality?
Pushed to trunk now.
>
> -- >8 --
>
> The macro-based concept checks are unmaintained and do not support C++11
> or later, so reject valid code. If nobody plans to update them w
On Thu, 21 Dec 2023, Lewis Hyatt wrote:
> In libcpp/files.cc, the function _cpp_has_header(), which implements
> __has_include and __has_include_next, does not check for a NULL return value
> from search_path_head(), leading to an ICE tripping an assert when
> _cpp_find_file() tries to use it. Fix
On 3/13/24 4:22 AM, Richard Biener wrote:
... this hunk is OK (please test and split it out separatley). In the spirit of
moving the stmt the least amount (in this case not schedule it within the
basic-block). In the same spirit one would choose an earlier basic-block
but only if the old c
On Tue, 12 Dec 2023, Lewis Hyatt wrote:
> When the file name for a #include directive is the result of stringifying a
> macro argument, libcpp needs to take some care to get the whitespace
> correct; in particular stringify_arg() needs to see a CPP_PADDING token
> between macro tokens so that it c
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-coun
On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new ma
> On Mar 11, 2024, at 13:09, Siddhesh Poyarekar wrote:
>
>
>
> On 2024-02-16 14:47, Qing Zhao wrote:
>> Including the following changes:
>> * The definition of the new internal function .ACCESS_WITH_SIZE
>> in internal-fn.def.
>> * C FE converts every reference to a FAM with a "counted_by"
Hi Chung-Lin, hi Thomas, hello world,
some thoughts glancing at the patch.
Chung-Lin Tang wrote:
There is still some shortcomings in the current state, mainly that only explicit-shaped
arrays can be used (like its C counterpart). Anything else is currently a bit more
complicated in the middle
Sid,
Thanks a lot for your time to review the code.
See my reply below:
On Mar 11, 2024, at 10:57, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
return true;
else
return targetm.attribute_takes_identifier_p (attr_id);
@@ -2806,6 +2811,53 @@ handle_strict_flex_arra
Hi Chung-Lin,
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641669.html
Chung-Lin Tang wrote:
this patch implements reductions for arrays and structs for OpenACC. Following
the pattern for OpenACC reductions [...]
(Stumbled over while looking at the Fortran patch, but applying to
> Am 13.03.2024 um 16:45 schrieb Jonathan Wakely :
>
> Every year I have to scroll down further and further to the useful part,
> and I'm getting too old to spend my time doing that! :)
>
> I suggested this on IRC and iains agreed. What do others think?
It feels a bit odd. Can we use html t
Hello All:
Common infrastructure using generic code for load store fusion of rs6000
target.
Generic code are implemented and defined that can be used in target specific
code for aarch64 and rs6000 target.
Generic code are implemeneted in gcc/pair-fusion-base.h,
gcc/pair-fusion-common.cc
and gc
Every year I have to scroll down further and further to the useful part,
and I'm getting too old to spend my time doing that! :)
I suggested this on IRC and iains agreed. What do others think?
-- >8 --
This seems more useful with the recent history first.
---
htdocs/develop.html | 819 +
Hello All:
Common infrastructure using generic code for load store fusion of rs6000
target.
This patch is split-patch 0 which uses generic code are implemented and defined
that can be used in target specific code for aarch64 and rs6000 target.
Generic code are implemeneted in gcc/pair-fusion-b
Hello All:
Common infrastructure using generic code for load store fusion of rs6000
target.
Generic code are implemented and defined that can be used in target specific
code for aarch64 and rs6000 target.
Generic code are implemeneted in gcc/pair-fusion-base.h,
gcc/pair-fusion-common.cc
and gc
This optimisation does not honour signed zeros, so should not be
enabled except with -fno-signed-zeros.
OK for master? I do not have commit rights for GCC, so if the patch
is fine would someone be able to commit for me? The bug is present
in all GCC versions from 12.1.0 onwards - is it possible to
Hello All:
Common infrastructure using generic code for load store fusion of rs6000
target.
This patch is split-patch 0 which uses generic code are implemented and defined
that can be used in target specific code for aarch64 and rs6000 target.
Generic code are implemeneted in gcc/pair-fusion-bas
Any unnamed structure field if not a member of the BTF_KIND_STRUCT.
For that reason, CO-RE access strings indexes should take that in
consideration. This patch adds a condition to the incrementer that
computes the index for the field access.
gcc/ChangeLog:
* config/bpf/core-builtins.cc (bp
Although part of all CO-RE relocation data, type based relocations do
not require an access string.
Initial implementation defined it as an empty string.
On the other hand, libbpf when parsing the CO-RE relocations verifies
that those strings would contain "0", otherwise reports an error.
This patc
This patch corrects bugs within the CO-RE builtin field expression
related builtins.
The following bugs were identified and corrected based on the expected
results of bpf-next selftests testsuite.
It addresses the following problems:
- Expressions with pointer dereferencing now point to the BTF st
On 2024-03-12 14:21, Jason Merrill wrote:
On 3/11/24 06:23, Torbjörn SVENSSON wrote:
Changes compared to v1:
- Added reference to r14-6517-gb7e4a4c626e in dg-bogus comment
- Changed arm-*-* to short_enums in target selector
- Updated commit message to align with above changes
As the entire
Committed the blow as requested by Jason in the patch for releases/gcc-13.
--
On arm-none-eabi, the test case fails with below warning on GCC13
.../null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:63:65: warning:
converting a packed 'enum obj_type' pointer (alignment 1) to a 'struct
connecti
Hello Richard:
Currently, code sinking will sink code at the use points with loop having same
nesting depth. The following patch improves code sinking by placing the sunk
code in begining of the block after the labels.
For example :
void bar();
int j;
void foo(int a, int b, int c, int d, int e,
If this insn is really used, we'll have something like
slti $r4,$r0,$r5
in the code. The assembler will reject it because slti wants 2
register operands and 1 immediate operand. But we've not got any bug
report for this, indicating this define_insn is unused at all.
Note that do_store_flag
On Tue, 2024-03-12 at 09:56 +0800, Chenghui Pan wrote:
> The behavior of non-zero unused bits in xvpermi.q instruction's
> third operand is undefined on LoongArch, according to our
> discussion (https://github.com/llvm/llvm-project/pull/83540),
> we think that keeping original insn operand as unmod
Ping!
On 3/7/24 4:14 PM, Tejas Belagod wrote:
This patch fixes a bug where vect_recog_abd_pattern called vect_convert_output
with the incorrect vecitype for the corresponding pattern_stmt.
vect_convert_output expects vecitype to be the vector form of the scalar type
of the LHS of pattern_stmt, b
On 13/03/2024 12:12, Maxim Kuvyrkov wrote:
Changes in v2:
- Better changelog entry.
- NFC.
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- F
Changes in v2:
- Better changelog entry.
- NFC.
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Execut
On 13 Mar 2024, at 12:30, Iain Sandoe wrote:
>
>> On 7 Mar 2024, at 16:48, Dimitry Andric wrote:
>>
>> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
>>
>> Use INCLUDE_VECTOR before including system.h, instead of directly
>> including , to avoid running into poisoned identifiers.
>
On Wed, 13 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> gimple-ssa-store-merging.cc tests bswap_optab in 3 different places,
> in 2 of them it has special exception for double-word bswap using pair
> of word-mode bswap optabs, but in the last one it doesn't.
>
> The following patch changes even the
> On Mar 13, 2024, at 15:25, Richard Earnshaw
> wrote:
>
>
>
> On 13/03/2024 10:58, Maxim Kuvyrkov wrote:
>> This patch has been tested on
>> - aarch64-linux-gnu
>> - arm-linux-gnueabihf (VFP, NEON disabled by default),
>> - arm-none-eabi (Soft-FP)
>> with the following [expected] differences
On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze wrote:
>
> Previously, calling erase(key) on both std::map and std::set
> would execute that same code that std::multi{map,set} would.
> However, doing that is unnecessary because std::{map,set}
> guarantee that all elements are unique.
>
> It is reason
On 12/03/2024 14:08, Richard Ball wrote:
The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.
Ok for trunk?
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Hi Dimitry,
> On 7 Mar 2024, at 16:48, Dimitry Andric wrote:
>
> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
>
> Use INCLUDE_VECTOR before including system.h, instead of directly
> including , to avoid running into poisoned identifiers.
I would say that the patch itself is obvious
On 13/03/2024 10:58, Maxim Kuvyrkov wrote:
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Execut
On Wed, Mar 13, 2024 at 12:18:45PM +0100, Jan Hubicka wrote:
> > On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > > > So the ipa_jump_func are I think the only thing that actually can
> > > > > differ
> > > > > on the ICF merging candidates from value range POV.
> > > >
> > > >
> On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > > So the ipa_jump_func are I think the only thing that actually can differ
> > > > on the ICF merging candidates from value range POV.
> > >
> > > I agree. Btw, I would have approved the original patch in this
> > > thread that
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Executed from: gcc:gcc.dg/vect/vect.exp
gcc:gcc.dg/v
On Wed, Mar 13, 2024 at 06:05:29PM +0800, Xi Ruoyao wrote:
> On Tue, 2024-03-12 at 17:19 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote:
> > > With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> > > __vfprintf_chk ends up calling __vpri
Hi!
gimple-ssa-store-merging.cc tests bswap_optab in 3 different places,
in 2 of them it has special exception for double-word bswap using pair
of word-mode bswap optabs, but in the last one it doesn't.
The following patch changes even the last spot.
We don't handle 128-bit bswaps in the passes a
On Wed, Mar 13, 2024 at 10:02 AM Ajit Agarwal wrote:
>
> Hello All:
>
> Currently, code sinking will sink code at the use points with loop having same
> nesting depth. The following patch improves code sinking by placing the sunk
> code in immediate dominator with same loop nest depth.
>
> Changes
On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > So the ipa_jump_func are I think the only thing that actually can differ
> > > on the ICF merging candidates from value range POV.
> >
> > I agree. Btw, I would have approved the original patch in this
> > thread that wipes SSA_NA
On Tue, 2024-03-12 at 17:19 +0100, Jakub Jelinek wrote:
> On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote:
> > With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> > __vfprintf_chk ends up calling __vprintf_chk rather than vprintf.
Do we really want to support adding r
On Wed, 13 Mar 2024, Jan Hubicka wrote:
> > On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > > > I am sorry for delaying this. I made the variant that simp
> On Tue, 12 Mar 2024, Jakub Jelinek wrote:
>
> > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > > I am sorry for delaying this. I made the variant that simply compares
> > > > value range of functions and pr
On Wed, 2024-03-13 at 10:24 +0800, Xi Ruoyao wrote:
> return TARGET_EXPLICIT_RELOCS
> - ? "pcalau12i\t$r4,%%desc_pc_hi20(%1)\n\
> - \taddi.d\t%2,$r0,%%desc_pc_lo12(%1)\n\
> - \tlu32i.d\t%2,%%desc64_pc_lo20(%1)\n\
> - \tlu52i.d\t%2,%2,%%desc64_pc_hi12(%1)\n\
> - \tadd.d\t$r
Hello All:
For rs6000 target we see redundant zero and sign extension and done to improve
ree pass to eliminate such redundant zero and sign extension. Support of
zero_extend/sign_extend/AND. Also support of AND with extension with different
constants like 0x7/0x7F/0x7 other than 1.
Changes s
On Wed, 2024-03-13 at 11:06 +0800, mengqinggang wrote:
>
> 在 2024/3/13 上午6:15, Xi Ruoyao 写道:
> > On Tue, 2024-03-12 at 17:20 +0800, mengqinggang wrote:
> > > +(define_insn "@got_load_tls_desc"
> > > + [(set (match_operand:P 0 "register_operand" "=r")
> > > + (unspec:P
> > > + [(match_operand:
On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote:
> Non-parallel build can fail, depending on the ./configure parameters -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
>
> The change below does fix the problem.
CCing build system maintainers and the Go maintainer.
While
Hi Chung-Lin!
On 2024-03-07T17:02:02+0900, Chung-Lin Tang wrote:
> On 2023/10/26 6:43 PM, Thomas Schwinge wrote:
>> +++ b/gcc/tree.h
>> @@ -1813,6 +1813,14 @@ class auto_suppress_location_wrappers
>> #define OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE(NODE) \
>> (OMP_CLAUSE_SUBCODE
Hi Harald,
This looks good to me. The testcase gives the same result with other brands.
OK for mainline and for backporting.
Thanks
Paul
On Tue, 12 Mar 2024 at 22:12, Harald Anlauf wrote:
> Dear all,
>
> here's another small fix: IS_CONTIGUOUS did erroneously always
> return .true. for CLAS
Hello All:
Currently, code sinking will sink code at the use points with loop having same
nesting depth. The following patch improves code sinking by placing the sunk
code in immediate dominator with same loop nest depth.
Changes since v11:
Reorganization of the code.
For example :
void bar();
On Wed, 13 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because for large/huge _BitInt bitfield
> loads/stores we use the DECL_BIT_FIELD_REPRESENTATIVE as the underlying
> "var" and indexes into it can be larger than the precision of the
> bitfield might normally allow.
>
Hi!
The following testcase ICEs, because for large/huge _BitInt bitfield
loads/stores we use the DECL_BIT_FIELD_REPRESENTATIVE as the underlying
"var" and indexes into it can be larger than the precision of the
bitfield might normally allow.
The following patch fixes that by passing NULL_TREE typ
On Tue, Mar 12, 2024 at 02:46:07PM +0100, Richard Biener wrote:
> OK.
Thanks. Here is the actually committed version which uses
gsi_safe_insert_before instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk.
2024-03-13 Jakub Jelinek
PR sanitizer/112709
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 02:31:28PM +0100, Richard Biener wrote:
> > Ah, yeah, I see :/
> >
> > > So, the intention of edge_before_returns_twice_call is just that
> > > it in the common case just finds the non-EDGE_ABNORMAL edge if there is
> > > one,
>
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > I am sorry for delaying this. I made the variant that simply compares
> > > value range of functions and prevents mergi
61 matches
Mail list logo
