On Wed, 10 Apr 2024, Uros Bizjak wrote:
> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> wrote:
> >
> > On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> > > If there are no further comments, I plan to commit the referred patch
> > > to the mainline on Wednesday. The latest ver
Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao:
>
> > On Apr 10, 2024, at 15:05, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
> > > Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> > > > On Fri, 29 Mar 2024, Qing Z
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-11 11:51
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Remove -Wno-psabi for test build option [NFC]
From: Pan Li
Just notice there are some test case still have -Wno-psabi option,
which is deprecated no
From: Pan Li
Just notice there are some test case still have -Wno-psabi option,
which is deprecated now. Remove them all for riscv test cases.
The below test are passed for this patch.
* The riscv rvv regression test.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/pr109244.C: Re
On 4/10/24 20:00, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 17:39, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote:
On 3
Committed, thanks Juzhe and Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, April 11, 2024 10:50 AM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode
switch
I was thinking we may guarded with
I was thinking we may guarded with TARGET_VECTOR and TARGET_HARD_FLOAT
or checking with ABI in riscv_function_value_regno_p, however I think
it's fine with current implementation (no checking) after checking all
use site of `targetm.calls.function_value_regno_p`, so LGTM :)
Thanks Pan for fixing t
Thanks for fixing it. LGTM from my side.
I prefer wait kito for another ACK.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-11 10:16
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch
From: Pan Li
This patch
From: Pan Li
This patch would like to fix a ICE in mode sw for below example code.
during RTL pass: mode_sw
test.c: In function ‘vbool16_t j(vuint64m4_t)’:
test.c:15:1: internal compiler error: in create_pre_exit, at
mode-switching.cc:451
15 | }
| ^
0x3978f12 create_pre_exit
__R
On Wed, 10 Apr 2024, Jason Merrill wrote:
> On 4/10/24 17:39, Patrick Palka wrote:
> > On Wed, 10 Apr 2024, Jason Merrill wrote:
> >
> > > On 3/12/24 10:51, Patrick Palka wrote:
> > > > On Tue, 12 Mar 2024, Patrick Palka wrote:
> > > > > On Tue, 12 Mar 2024, Jason Merrill wrote:
> > > > > > On 3/
> Date: Tue, 9 Apr 2024 15:18:10 -0500
> From: Segher Boessenkool
> All (target-specific) new testsuite failures are just like that: bad
> testcases!
With a touch of bad assumptions by port-specific code, no
doubt. Maybe also rtx costs including my pet peeve, the
default implementation of insn_
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue, 27 Feb 2024, Patrick Palka wrote:
Subject: [PATCH] c++/modules: local type merging [PR99426]
One known missing piece in the modules implementation is merging of a
str
On 4/10/24 17:39, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote:
On 3/11/24 12:53, Patrick Palka wrote:
r13-6452-g341e6cd8d603a3 made build_extra_args
On Wed, 10 Apr 2024, Qing Zhao wrote:
> Okay, the above is very clear, thanks a lot for the explanation.
> So, basically, for “counted-by” attribute:
> **The following is good:
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) };
> struct f {
> int b;
> int c;
>
On 2024-03-29 12:07, Qing Zhao wrote:
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible t
On 2024-03-29 12:07, 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-counted-by-bounds-2.c: New test.
On 2024-03-29 12:07, 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 macro EXPECT.
* gcc.dg/f
On Wed, 10 Apr 2024, Jason Merrill wrote:
> On 3/12/24 10:51, Patrick Palka wrote:
> > On Tue, 12 Mar 2024, Patrick Palka wrote:
> > > On Tue, 12 Mar 2024, Jason Merrill wrote:
> > > > On 3/11/24 12:53, Patrick Palka wrote:
> > > > >
> > > > > r13-6452-g341e6cd8d603a3 made build_extra_args walk e
I went through all cp/ commits in GCC 14 and documented a few interesting
user-visible changes, modulo Modules.
W3 validated. Pushed.
commit d65752191baaa137eb6d604b802e7b9170a39752
Author: Marek Polacek
Date: Wed Apr 10 17:21:09 2024 -0400
gcc-14/changes: Document more C++ changes
diff
Tested lightly by hand.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9900-g960e07d73a5295.
gcc/analyzer/ChangeLog:
* infinite-recursion.cc: Include "diagnostic-format-sarif.h".
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9897-g7f6599a201be2a.
gcc/ChangeLog:
* doc/analyzer.texi: Various tweaks.
Signed-off-by: David Malcolm
---
gcc/doc/analyzer.texi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff -
I made several attempts to fix this properly, but for now apply
a band-aid to at least prevent crashing on such cases.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9902-g4a94551d7eaaf7.
g
Tested lightly by hand.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9898-g115d5c6b009456.
gcc/analyzer/ChangeLog:
* sm-taint.cc (tainted_allocation_size::tainted_allocation_size):
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9896-g082374f6570a31.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/memset-1.c: Clarify some comments.
Signed-off-by: David Malcolm
---
gcc/testsuite/c-c++-common/analyzer/memset-1.c | 4 ++--
1 file changed, 2 i
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9895-gd09d70cdb2a4bc.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/copy_from_user-1.c: Add missing directives for an
analyzer test.
Tested lightly by hand.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9901-g107b0e63be023c.
gcc/analyzer/ChangeLog:
* infinite-loop.cc: Include "diagnostic-format-sarif.h".
Tested lightly by hand.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9899-g7a49d5dc0ef345.
gcc/analyzer/ChangeLog:
* call-details.cc: Include "diagnostic-format-sarif.h".
(
Hi Paul!
On 4/10/24 10:25, Paul Richard Thomas wrote:
Hi All,
This patch corrects incorrect results from assignment of unlimited
polymorphic function results both in assignment statements and allocation
with source.
The first chunk in trans-array.cc ensures that the array dtype is set to
the s
Thanks a lot for your review.
Will fix these typos before committing to GCC15.
Qing
> On Apr 10, 2024, at 14:36, Joseph Myers wrote:
>
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
>> +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to
>> + the object that represents its c
> On Apr 10, 2024, at 15:05, Martin Uecker wrote:
>
> Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
>> Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
>>> On Fri, 29 Mar 2024, Qing Zhao wrote:
>>>
+ /* Issue error when there is a counted_by attribute
> On Apr 10, 2024, at 14:44, Joseph Myers wrote:
>
> On Wed, 10 Apr 2024, Qing Zhao wrote:
>
>> A stupid question first, the same scope means the same file? (Or same
>> function)
>
> struct X { int a; };
> struct X { int a; };
>
> is an example of the same scope (file scope, in this case).
Hi Indu,
On 4/10/24 11:25, Indu Bhagat wrote:
> Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF
> generation, however: BTF emission was currently decrementing the vlen
> (indicating the number of members) to skip members of type CTF_K_UNKNOWN
> altogether, but still emittin
On 4/10/24 11:25, Indu Bhagat wrote:
> PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in
> a struct and -gctf1
>
> The CTF generation in GCC does not have a mechanism to roll-back an
> already added type. In this testcase presented in the PR, we hit a
> representation
Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
> Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> > On Fri, 29 Mar 2024, Qing Zhao wrote:
> >
> > > + /* Issue error when there is a counted_by attribute with a different
> > > + field as the argument for the
On Wed, Apr 10, 2024 at 07:51:44PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > On Wed, Apr 10, 2024 at 05:42:05PM +0100, Richard Sandiford wrote:
> >> Andrew Carlotti writes:
> >> > On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
> >> >> Andrew Carlotti write
On Tue, 9 Apr 2024, Jason Merrill wrote:
> On 3/5/24 10:31, Patrick Palka wrote:
> > On Tue, 27 Feb 2024, Patrick Palka wrote:
> >
> > Subject: [PATCH] c++/modules: local type merging [PR99426]
> >
> > One known missing piece in the modules implementation is merging of a
> > streamed-in local ty
Andrew Carlotti writes:
> On Wed, Apr 10, 2024 at 05:42:05PM +0100, Richard Sandiford wrote:
>> Andrew Carlotti writes:
>> > On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
>> >> Andrew Carlotti writes:
>> >> > The first three patches are trivial changes to the feature list to
On Wed, 10 Apr 2024, Qing Zhao wrote:
> A stupid question first, the same scope means the same file? (Or same
> function)
struct X { int a; };
struct X { int a; };
is an example of the same scope (file scope, in this case). The
structures must have the same contents (in an appropriate sense)
Evgeny Karpov writes:
> Hello,
>
> v2 is ready for the review!
> Based on the v1 review:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#646203
>
> Testing for the x86_64-w64-mingw32 target is in progress to avoid
> regression due to refactoring.
Thanks for the updates and
The C front-end changes in this patch are OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
On Fri, 29 Mar 2024, Qing Zhao wrote:
> +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to
> + the object that represents its counted_by per the attribute counted_by
> + attached to this field if it's a flexible array member field, otherwise
> + return NULL_TREE.
> +
The C front-end changes in this patch are OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 02:17:39 +0100
> Subject: [PATCH v2 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW
> Options"
>
> Rename "x86 Windows Options" to "Cygwin and MinGW Options".
> It will be used also for AArch64.
>
> gcc/ChangeLog:
>
>
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 10:49:28 +0100
> Subject: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for
> AArch64
>
> Define Cygwin and MinGW environment such as types, SEH definitions,
> shared libraries, etc.
>
> gcc/ChangeLog:
>
> * con
On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
wrote:
>
> On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> > If there are no further comments, I plan to commit the referred patch
> > to the mainline on Wednesday. The latest version can be considered an
> > obvious patch that solv
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 01:55:47 +0100
> Subject: [PATCH v2 04/13] aarch64: Add aarch64-w64-mingw32 COFF
>
> Define ASM specific for COFF format on AArch64.
>
> gcc/ChangeLog:
>
> * config.gcc: Add COFF format support definitions.
> * config/aa
PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a
struct and -gctf1
The CTF generation in GCC does not have a mechanism to roll-back an
already added type. In this testcase presented in the PR, we hit a
representation limit in CTF slices (for a member of a struct) an
Hi,
The patch series includes two patches: first one is a fix for PR
debug/112878 and the second one is for an existing BTF generation issue.
Testing Notes:
- Regression tested on x86_64-linux-gnu
- Tested btf.exp, ctf.exp, bpf.exp for --target=bpf-unknown-none
Thanks,
Indu Bhagat (2):
ctf:
Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF
generation, however: BTF emission was currently decrementing the vlen
(indicating the number of members) to skip members of type CTF_K_UNKNOWN
altogether, but still emitting the BTF for the corresponding member (in
output_asm_b
Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
> > + /* Issue error when there is a counted_by attribute with a different
> > + field as the argument for the same flexible array member field. */
>
> There's another case of this to
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 09:56:59 +0100
> Subject: [PATCH v2 03/13] aarch64: Mark x18 register as a fixed register for
> MS ABI
>
> Define the MS ABI for aarch64-w64-mingw32.
> Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
> STATIC_CHAIN_REGNUM fo
Hello Alex:
On 10/04/24 7:52 pm, Alex Coplan wrote:
> Hi Ajit,
>
> On 10/04/2024 15:31, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 10/04/24 1:42 pm, Alex Coplan wrote:
>>> Hi Ajit,
>>>
>>> On 09/04/2024 20:59, Ajit Agarwal wrote:
Hello Alex:
On 09/04/24 8:39 pm, Alex Coplan wrote:
Sorry for the slow reply.
Evgeny Karpov writes:
> From: Zac Walker
> Date: Fri, 1 Mar 2024 01:45:13 +0100
> Subject: [PATCH v2 02/13] aarch64: The aarch64-w64-mingw32 target implements
> the MS ABI
>
> Two ABIs for aarch64 have been defined for different platforms.
>
> gcc/ChangeLog:
>
>
Thanks for the comments.
> On Apr 10, 2024, at 13:35, Joseph Myers wrote:
>
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
>> + /* Issue error when there is a counted_by attribute with a different
>> + field as the argument for the same flexible array member field. */
>
> There's another case
On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> If there are no further comments, I plan to commit the referred patch
> to the mainline on Wednesday. The latest version can be considered an
> obvious patch that solves certain oversight in the original
> implementation.
This is never
On Fri, Apr 05, 2024 at 02:37:08PM -0400, Marek Polacek wrote:
> > This function is passed explicit opts and opts_set arguments, so it
> > shouldn't be using flag_something macros nor OPTION_SET_P, as the former
> > use global_options.x_flag_something rather than opts->x_flag_something
> > and the
On Fri, 29 Mar 2024, Qing Zhao wrote:
> + /* Issue error when there is a counted_by attribute with a different
> + field as the argument for the same flexible array member field. */
There's another case of this to consider, though I'm not sure where best
to check for it (Martin might have
On 4/10/24 13:10, Richard Biener wrote:
On Wed, 10 Apr 2024, Jakub Jelinek wrote:
On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
The following fixes a mismatch in COMPOUND_EXPR handling in
tsubst_expr vs tsubst_stmt where the latter allows a stmt in
operand zero but the former
On Wed, Apr 10, 2024 at 07:10:52PM +0200, Richard Biener wrote:
> Ah, I saw the bugzilla patches and wanted this version to be sent
> because I think the COMPOUND_EXPR inconsistency is odd. So Jason,
> please still have a look, not necessarily because of the bug
> which can be fixed in multiple wa
On Wed, Apr 10, 2024 at 05:42:05PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
> >> Andrew Carlotti writes:
> >> > The first three patches are trivial changes to the feature list to
> >> > reflect
> >> > recent
Hi,
Patch to add AArch64 to the list of supported _BitInt(N) in
gcc-14/changes.html.
OK?diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
a7ba957110183f906938d935bfa17aaed2ba20c8..55ab8c14c6d0b54e05a5f266f25c8ef1a4f959bf
100644
--- a/htdocs/gcc-14/changes.html
+++ b/
On Wed, 10 Apr 2024, Jakub Jelinek wrote:
> On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
> > The following fixes a mismatch in COMPOUND_EXPR handling in
> > tsubst_expr vs tsubst_stmt where the latter allows a stmt in
> > operand zero but the former doesn't. This makes a differ
On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
> The following fixes a mismatch in COMPOUND_EXPR handling in
> tsubst_expr vs tsubst_stmt where the latter allows a stmt in
> operand zero but the former doesn't. This makes a difference
> for the case at hand because when the COMPOU
The following fixes a mismatch in COMPOUND_EXPR handling in
tsubst_expr vs tsubst_stmt where the latter allows a stmt in
operand zero but the former doesn't. This makes a difference
for the case at hand because when the COMPOUND_EXPR is wrapped
inside an ANNOTATE_EXPR it gets handled by tsubst_exp
Andrew Carlotti writes:
> On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
>> Andrew Carlotti writes:
>> > The first three patches are trivial changes to the feature list to reflect
>> > recent changes in the ACLE. Patch 4 removes most of the FMV
>> > multiversioning
>> > feat
On 4/10/24 09:06, Jakub Jelinek wrote:
Hi!
The following testcase ICEs starting with the r14-4229 PR111529
change which moved ANNOTATE_EXPR handling from tsubst_expr to
tsubst_copy_and_build.
ANNOTATE_EXPR is only allowed in the IL to wrap a loop condition,
and the loop condition of while/for lo
On 4/10/24 11:26, Patrick Palka wrote:
On Wed, 10 Apr 2024, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 2/16/24 10:06, Patrick Palka wrote:
On Thu, 15 Feb 2024, Patrick Palka wrote:
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as
The following makes sure to restrict WIDEN_MULT*_EXPR to a mode
precision final compute type as the mode is used to find the optab
and type checking chokes when seeing bit-precisions later which
would likely also not properly expanded to RTL.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pu
On Wed, 10 Apr 2024 00:58:00 PDT (-0700), kito.ch...@sifive.com wrote:
---
htdocs/gcc-14/changes.html | 155 -
1 file changed, 154 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 2d8968cf..6cbb2e8f 10064
On 3/27/24 10:01, Patrick Palka wrote:
On Mon, 25 Mar 2024, Patrick Palka wrote:
On Mon, 25 Mar 2024, Patrick Palka wrote:
The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_par
On Wed, 10 Apr 2024, Patrick Palka wrote:
>
> On Tue, 9 Apr 2024, Jason Merrill wrote:
>
> > On 2/16/24 10:06, Patrick Palka wrote:
> > > On Thu, 15 Feb 2024, Patrick Palka wrote:
> > >
> > > > One would expect consecutive calls to bytes_in/out::b for streaming
> > > > adjacent bits, as we do f
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
The std/time/year_month_day/io.cc test assumes that %x in the fr_FR
locale is %d/%m/%Y but on FreeBSD it is %d.%m.%Y instead. Make the test
PASS for either format.
Similarly, 27_io/manipulators/extended/get_time/char/2.cc expect
On Tue, 9 Apr 2024, Jason Merrill wrote:
> On 2/16/24 10:06, Patrick Palka wrote:
> > On Thu, 15 Feb 2024, Patrick Palka wrote:
> >
> > > One would expect consecutive calls to bytes_in/out::b for streaming
> > > adjacent bits, as we do for tree flag streaming, to at least be
> > > optimized by
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
Although POSIX requires ELOOP, FreeBSD documents that openat with
O_NOFOLLOW returns EMLINK if the last component of a filename is a
symbolic link. Check for EMLINK as well as ELOOP, so that the TOCTTOU
mitigation in remove_all
Hi,
Michal Jireš found out that the link to Feature Test Macros on the
Porting to GCC 14 page was broken, it misses a "/latest/" directory in
the middle of the path.
I'll commit the following as obvious.
Thanks,
Martin
---
htdocs/gcc-14/porting_to.html | 2 +-
1 file changed, 1 insertion(+),
Hi Ajit,
On 10/04/2024 15:31, Ajit Agarwal wrote:
> Hello Alex:
>
> On 10/04/24 1:42 pm, Alex Coplan wrote:
> > Hi Ajit,
> >
> > On 09/04/2024 20:59, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 09/04/24 8:39 pm, Alex Coplan wrote:
> >>> On 09/04/2024 20:01, Ajit Agarwal wrote:
> Hello
On Wed, 10 Apr 2024 00:57:59 PDT (-0700), sch...@suse.de wrote:
On Apr 09 2024, Palmer Dabbelt wrote:
I didn't actually regenerate this as I can't figure out how,
make regenerate-opt-urls
Ya, that's what the CI says too. I think I might just have a broken
build tree, something is mixed up
On Tue, 09 Apr 2024 07:57:24 PDT (-0700), ishitatsuy...@gmail.com wrote:
Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Regenerated.
---
gcc/config/riscv/riscv.opt.urls | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/con
ping?
On Tue, 6 Feb 2024 at 10:26, Christophe Lyon wrote:
>
> ping?
>
> On Thu, 25 Jan 2024 at 16:54, Christophe Lyon
> wrote:
> >
> > On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> > >
> > > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > > >
> > > > GDB emits end of lines as
Ping!
Kind regards,
Torbjörn
On 2024-03-25 15:59, Yvan ROUX - foss wrote:
Ping!
Rgds,
Yvan
From: Torbjorn SVENSSON - foss
Sent: Friday, March 15, 2024 11:32 AM
To: David Malcolm; Alexandre Oliva
Cc: gcc-patches@gcc.gnu.org; Yvan ROUX - foss
Subject: [PI
Hi!
The following testcase ICEs starting with the r14-4229 PR111529
change which moved ANNOTATE_EXPR handling from tsubst_expr to
tsubst_copy_and_build.
ANNOTATE_EXPR is only allowed in the IL to wrap a loop condition,
and the loop condition of while/for loops can be a COMPOUND_EXPR
with DECL_EXPR
On Tue, Apr 09, 2024 at 04:33:10PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > There was an assumption in some places that the aarch64_fmv_feature_data
> > array contained FEAT_MAX elements. While this assumption held up till
> > now, it is safer and more flexible to use the arr
On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > The first three patches are trivial changes to the feature list to reflect
> > recent changes in the ACLE. Patch 4 removes most of the FMV multiversioning
> > features that don't work at the moment, a
Hi!
On Wed, Apr 03, 2024 at 11:48:20AM +0200, Jakub Jelinek wrote:
> I'd like to ping the following patches:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
> PR111284 P2
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html
> PR114409 (part of a P1)
>
> http
On Tue, Apr 9, 2024 at 10:39 PM Alan Modra wrote:
>
> On Tue, Apr 09, 2024 at 07:24:33AM -0700, H.J. Lu wrote:
> > Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid
> > the sanitizer configure check failure.
>
> OK for binutils. (I just fixed my local copy of autoconf so I
I think this is considerably nicer than the macro version, but it can
definitely wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__compare): New
function template.
(operator==, operator!=, operator<, operator>, operator<=)
"Andre Vieira (lists)" writes:
> Added the target check, also had to change some of the assembly checking
> due to changes upstream, the assembly is still valid, but we do extend
> where not necessary, I do believe that's a general issue though.
>
> The _BitInt(N > 64) codegen for non-powers of
"Andre Vieira (lists)" writes:
> @@ -6907,6 +6938,11 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const
> function_arg_info &arg)
> && (!alignment || abi_break_gcc_9 < alignment)
> && (!abi_break_gcc_13 || alignment < abi_break_gcc_13));
>
> + /* _BitInt(N) was only
Hello Alex/Richard:
All comments are addressed in this version-1 of the patch.
Common infrastructure of load store pair fusion is divded into target
independent and target dependent changed code.
Target independent code is the Generic code with pure virtual function
to interface betwwen target i
Hello Alex:
On 10/04/24 1:42 pm, Alex Coplan wrote:
> Hi Ajit,
>
> On 09/04/2024 20:59, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 09/04/24 8:39 pm, Alex Coplan wrote:
>>> On 09/04/2024 20:01, Ajit Agarwal wrote:
Hello Alex:
On 09/04/24 7:29 pm, Alex Coplan wrote:
> On 09/04/2
Added the target check, also had to change some of the assembly checking
due to changes upstream, the assembly is still valid, but we do extend
where not necessary, I do believe that's a general issue though.
The _BitInt(N > 64) codegen for non-powers of 2 did get worse, we see
similar codegen
Hey,
Added the warn_pcs_change_le_gcc14 variable and changed the uses of
warn_pcs_change to use this new variable.
Also fixed an issue with the loop through TREE_FIELDS to avoid an ICE
during bootstrap.
OK for trunk?
Bootstrapped and regression tested on aarch64-unknown-linux-gnu.
Kind rega
Tested x86_64-linux.
Since this only affects C++20 and later (except for adding [[nodiscard]]
to relational ops) it seems OK for trunk now.
-- >8 --
Implement the changes from P2944R3 which add constraints to the
comparison operators of std::pair, std::tuple, and std::variant.
The paper also ch
Tested x86_64-linux.
This is just a minor clean-up and could wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE):
Simplify.
---
libstdc++-v3/include/std/variant | 20 +---
1 file changed, 9 insertions(+)
Tested x86_64-linux.
Since this only affects C++26 it seems OK for trunk now.
-- >8 --
This C++26 change was just approved in Tokyo, in P2944R3. It adds
operator== and operator<=> overloads to std::reference_wrapper.
The operator<=> overloads in the paper cause compilation errors for any
type w
Tested x86_64-linux.
Since this only affects C++20 and later it seems OK for trunk now.
-- >8 --
I'm only treating this as a DR for C++20 for now, because it's less work
and only requires changes to operator== and operator<=>. To do this for
older standards would require changes to the six relat
Hi All,
This patch corrects incorrect results from assignment of unlimited
polymorphic function results both in assignment statements and allocation
with source.
The first chunk in trans-array.cc ensures that the array dtype is set to
the source dtype. The second chunk ensures that the lhs _len f
Hi Ajit,
On 09/04/2024 20:59, Ajit Agarwal wrote:
> Hello Alex:
>
> On 09/04/24 8:39 pm, Alex Coplan wrote:
> > On 09/04/2024 20:01, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 09/04/24 7:29 pm, Alex Coplan wrote:
> >>> On 09/04/2024 17:30, Ajit Agarwal wrote:
>
>
> On 05/04/
on 2024/4/10 15:11, Richard Biener wrote:
> On Wed, Apr 10, 2024 at 8:24 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> pr113359-2_*.c define a struct having unsigned long type
>> members ay and az which have 4 bytes size at -m32, while
>> the related constants CL1 and CL2 used for equality check
>> are alwa
---
htdocs/gcc-14/changes.html | 155 -
1 file changed, 154 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 2d8968cf..6cbb2e8f 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -7
1 - 100 of 103 matches
Mail list logo
