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 always 8 bytes, it makes compiler consider the below
69 if (a.ay != CL1)
70 __builtin_abort ();
always to
Hi!
On 2024-04-09T09:24:29-0700, Palmer Dabbelt wrote:
> On Tue, 09 Apr 2024 01:04:34 PDT (-0700), buga...@gmail.com wrote:
>> On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge
>> wrote:
>>> Thanks, pushed to trunk branch:
>>>
>>> - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move
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 always 8 bytes, it makes compiler consider the below
>
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
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
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
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
"Andre Vieira (lists)" writes:
> @@ -6907,6 +6938,11 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const
> function_arg_info )
> && (!alignment || abi_break_gcc_9 < alignment)
> && (!abi_break_gcc_13 || alignment < abi_break_gcc_13));
>
> + /* _BitInt(N) was only
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
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
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,
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
"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
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<=)
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)
>
>
On Apr 09 2024, Palmer Dabbelt wrote:
> I didn't actually regenerate this as I can't figure out how,
make regenerate-opt-urls
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
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
---
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
@@
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
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
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
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
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
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
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
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
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
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:
>
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
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
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
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:
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
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(+),
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
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
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 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
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 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:
>
>
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
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
+++
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
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
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.
> *
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
> 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 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
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,
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
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
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
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
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
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
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
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
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:
The C front-end changes in this patch are OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
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.
> +
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
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
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
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
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
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
> 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 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
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
>> >
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
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
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:
>
>
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)
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:
>
> *
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)
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
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
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.
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
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
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.
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
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.
*
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
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".
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
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
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".
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 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
> 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
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".
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
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;
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
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
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
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:
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
1 - 100 of 102 matches
Mail list logo
