On Wed, Apr 24, 2024 at 06:05:03PM +0800, Lehua Ding wrote:
> This patch add a new DF problem, named DF_LIVE_SUBREG. This problem
> is extended from the DF_LR problem and support track the subreg liveness
> of multireg pseudo if these pseudo satisfy the following conditions:
>
> 1. the mode size
Am 24.03.2024 um 22:34 schrieb Björn Schäpers:
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration should be moved into
ops-common.h, since then we could use stat_type
Am 15.03.2024 um 21:40 schrieb Björn Schäpers:
Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor:
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn
On 4/19/24 09:18, Nathaniel Shead wrote:
On Mon, Apr 15, 2024 at 02:49:35PM +1000, Nathaniel Shead wrote:
I took another look at this patch and have split it into two, one (this
one) to standardise the error messages used and prepare
'module_may_redeclare' for use with temploid friends, and anot
On Wed, 2024-04-24 at 17:05 -0400, Patrick Palka wrote:
> On Wed, 24 Apr 2024, Jason Merrill wrote:
>
> > On 4/24/24 13:22, Patrick Palka wrote:
> > > Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in
> > > progress,
> > > does this look OK if successful?
> > >
> > > -- >8 --
> > >
> > >
Hi David.
OK. Thanks for the patch.
> BTF is the standard debug info used with BPF programs, so it makes sense
> to default to BTF rather than DWARF.
>
> Tested on x86_64-linux-gnu host for bpf-unknown-none target.
>
> gcc/
> * config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG
On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
> Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
> rather set it to some stub like void_node?
I'll try that in stage1.
> Though with all these changes, it's probably better to go with your first
> patch f
On 4/23/24 08:52, Jakub Jelinek wrote:
On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
They weren't the same, one was trying to evaluate the convert_from_reference
with vc_glvalue, the other evaluates it without that and with vc_prvalue.
Now, I guess the
+ /* Undo convert_for_
Hi Andrew,
this patch adds support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation (https://llvm.org/docs/AMDGPUUsage.html)
lists those devices as unsupported by rocm-amdhsa.
As we have discussed elsewhere, I have tested the patch on an AMD Ryzen
5 5500U (also with d
> Am 25.04.2024 um 20:24 schrieb Jakub Jelinek :
>
> Hi!
>
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).
> So, we don't need to do the .weak
> Am 25.04.2024 um 17:44 schrieb Carlos O'Donell :
>
> Discussion is here:
> https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
>
> Rough consensus from Jakub Jelinek, Richard Biener and others is
> that maintainers are for the change.
Ok
Ri
Hi!
glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
dummy shared library with just some symbol versions for compatibility, but
all the pthread_* APIs are in libc.so.6).
So, we don't need to do the .weakref dances to check whether a program
has been linked with -lpthread
Hi!
tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly
Fortran, C just a little an
On Thu, 18 Apr 2024 at 21:34, Jonathan Wakely wrote:
>
> On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
> >
> > This completes the fixes to put all experimental symbols into
> > libstdc++exp.a.
> >
> > On trunk the libstdc++_libbacktrace.a was removed completely and its
> > contents aded to l
Hi Faust.
OK. Thanks for the patch.
> Compiling a BPF program with CO-RE relocations (and BTF) while also
> passing -gtoggle led to an inconsistent state where CO-RE support was
> enabled but BTF would not be generated, and this was not caught by the
> existing option parsing. This led to an I
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
The Doxygen-generated man pages for some new types need to be renamed to
use '::' instead of '_' in the filenames.
libstdc++-v3/ChangeLog:
* scripts/run_doxygen: Rename man pages for nested types.
---
libstdc++-v3/scr
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
Doxygen switched from \fC to \fR in its man page output:
https://github.com/doxygen/doxygen/pull/10497
This breaks our script that expects \fC so change the regaulr expression
to work with either style.
libstdc++-v3/ChangeLog:
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
---
libstdc++-v3/include/std/chrono | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/ch
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/doxygen/stdheader.cc (init_map): Add missing headers.
* doc/doxygen/user.cfg.in (EXCLUDE): Exclude generated files for
std::format and std::text_encoding.
---
libstdc++-v3/
Tested x86_64-linux. Pushed to trunk.
-- >8 --
It's not obvious why needs so add a
comment to it.
libstdc++-v3/ChangeLog:
* include/std/variant: Add comment to #include.
---
libstdc++-v3/include/std/variant | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++
> For the 20th anniversary of https://gcc.gnu.org/gcc-3.4/sparc-abi.html, a
> new calling convention incompatibility with the vendor compiler (and the
> ABI) has been discovered in 64-bit mode, affecting small structures
> containing arrays of floating-point components. The decision has been made
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.
gcc/testsuite/
* gcc.target/bpf/bpf-deb
Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing. This led to an ICE when generating the CO-RE
relocation info, si
Pushed to gcc-13
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
> all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
> but that wasn't true. Only the symbols from the latter were added to
> libst
Discussion is here:
https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
Rough consensus from Jakub Jelinek, Richard Biener and others is
that maintainers are for the change.
This changes the contribution notes to allow it.
---
htdocs/contribute.ht
At this point the kernel headers that almost all BPF programs use
contain pseudo-C inline assembly and having the GNU toolchain using
the conventional assembly syntax by default would force users to
specify the command-line option explicitly almost all of the time,
which is very inconvenient.
This
On 4/25/24 07:22, Jakub Jelinek wrote:
On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
I've tried the following patch, but unfortunately that lead to large
number of regressions:
+FAIL: g++.dg/cpp0x/initlist25.C -std=c++17 (test for excess errors)
So the reduced testcase for th
On 25/04/2024 11:51, Tobias Burnus wrote:
Motivated by a surprise of a colleague that with -m32,
no offload dumps were created; that's because mkoffload
does not process host binaries when the are 32bit (i.e. ilp32).
Internally, that done as follows: The host compiler passes to
'mkoffload' the u
Hi Richard,
I committed this combined patch (with Cortex-A520) for trunk
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cab53aae43cf94171b01320c08302e47a5daa391
Am I ok to commit just the Cortex-A510 half into gcc-12 and gcc-13.
Thanks,
Richard Ball
From: Richard
Hi Torbjorn,
Thanks very much for the comments.
I think given that the code that handles this, is within a
FOREACH_FUNCTION_ARGS loop.
It seems a fairly safe assumption that if the code works for one that it will
work for all.
To go back and add extra tests to me seems a little overkill.
Kind R
On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
> I've tried the following patch, but unfortunately that lead to large
> number of regressions:
> +FAIL: g++.dg/cpp0x/initlist25.C -std=c++17 (test for excess errors)
So the reduced testcase for this is
template struct A {
T a1;
> On Apr 25, 2024, at 10:13, Siddhesh Poyarekar wrote:
>
> On 2024-04-25 10:06, Qing Zhao wrote:
>> gcc/testsuite/ChangeLog:
>> * c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
>> * c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
>> * c-c++-common/fam-
On 4/22/24 4:07 PM, 钟居哲 wrote:
Apologize that we didn't post our (me, kito and Li Pan) disscussions.
This is the story:
We found that my previous patches which support highpart register
overlap with register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/
On 2024-04-25 10:06, Qing Zhao wrote:
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
Sorry I should
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
.../fam-in-union-alone-in-struct-1.c | 52
Hi,
This is the 2nd version for
Allow flexible array members in unions and alone in structures [PR53548]
(for your reference, the 1st version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649737.html)
compared to the 1st version, the major difference are:
A. C FE updates based on
to support flexible array members in unions and alone in structures.
Adjust testcases for flexible array member
in union and alone in structure extension.
gcc/c/ChangeLog:
* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or al
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
https://gcc.gnu.org/bugzilla/show_bu
When we use unloop_loops we have to make sure to have loops ordered
inner to outer as otherwise we can wreck inner loop structure where
unlooping relies on that being intact. The following re-sorts the
vector of to unloop loops after copy-header as that adds to the
vector in two places and the wr
On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
> when looking at a package build issue with GCC 14, Michal Jireš noted a
> different behavior of pragma GCC Target. This snippet tries to describe
> the gist of the problem. I have left it in the C section even though it
> is not rea
Hello,
when looking at a package build issue with GCC 14, Michal Jireš noted a
different behavior of pragma GCC Target. This snippet tries to describe
the gist of the problem. I have left it in the C section even though it
is not really C specific, but could not think of a good name for a new
se
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-04-25 19:23
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw; Patrick
O'Neill
Subject: [PATCH] RISC-V: Add testcase for PR114749.
Hi,
this adds a test case for PR114749.
Going to commit as obvious unle
On Wed, Apr 24, 2024 at 08:43:46PM -0400, Jason Merrill wrote:
> > Then can_alias_cdtor would return false, because it ends with:
> >/* Don't use aliases for weak/linkonce definitions unless we can put both
> > symbols in the same COMDAT group. */
> >return (DECL_INTERFACE_KNOWN (fn)
Hi,
On 2024-04-24 17:55, Richard Ball wrote:
This patch makes the following changes:
1) When calling a secure function from non-secure code then any arguments
smaller than 32-bits that are passed in registers are zero- or
sign-extended.
2) After a non-secure function returns into secure co
Hi!
While the C23 standard isn't officially release yet,
in 2011 we've changed __STDC_VERSION__ value for C11 already
in the month in which the new __STDC_VERSION__ value has been
finalized, so we want to change this now or wait
until we implement all the C23 features?
Note, seems Clang up to 17
Hi,
this adds a test case for PR114749.
Going to commit as obvious unless somebody complains.
Regards
Robin
gcc/testsuite/ChangeLog:
PR tree-optimization/114749
* gcc.target/riscv/rvv/autovec/pr114749.c: New test.
---
.../gcc.target/riscv/rvv/autovec/pr114749.c | 15 +++
Motivated by a surprise of a colleague that with -m32,
no offload dumps were created; that's because mkoffload
does not process host binaries when the are 32bit (i.e. ilp32).
Internally, that done as follows: The host compiler passes to
'mkoffload' the used host ABI, i.e. -foffload-abi=ilp32 or -
For the 20th anniversary of https://gcc.gnu.org/gcc-3.4/sparc-abi.html, a new
calling convention incompatibility with the vendor compiler (and the ABI) has
been discovered in 64-bit mode, affecting small structures containing arrays
of floating-point components. The decision has been made to fi
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, April 25, 2024 5:27 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Robin Dapp ; Li,
Pan2 ; Kito.cheng
Subject: Re: [PATCH v1] RISC-V: Add test cases for insn does not satisfy its
constraints [PR114714]
LGTM. THANKS
___
On 24/04/2024 16:55, Richard Ball wrote:
> This patch makes the following changes:
>
> 1) When calling a secure function from non-secure code then any arguments
>smaller than 32-bits that are passed in registers are zero- or
> sign-extended.
> 2) After a non-secure function returns into secur
LGTM. THANKS
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-25 17:25
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li; Kito Cheng
Subject: [PATCH v1] RISC-V: Add test cases for insn does not satisfy its
constraints [PR114714]
From: Pan Li
We have one ICE when RVV register o
From: Pan Li
We have one ICE when RVV register overlap is enabled. We reverted this
feature as it is in stage 4 and there is no much time to figure a better
solution for this. Thus, for now add the related test cases which will
trigger ICE when register overlap enabled.
This will gate the RVV
Bitcount operations popcount, clz, and ctz are emulated for narrow modes
in case an operation is only supported for wider modes. Beside that ctz
may be emulated via clz in expand_ctz. Reflect this in
expression_expensive_p.
I considered the emulation of ctz via clz as not expensive since this
ba
53 matches
Mail list logo
