For example:
struct PP {
size_t count2;
char other1;
char *array2 __attribute__ ((counted_by (count2)));
int other2;
} *pp;
specifies that the "array2" is an array that is pointed by the
pointer field, and its number of elements is given by the field
"count2" in the same structure.
gcc/c-
Hi,
This is the 4th version of the patch set to extend "counted_by" attribute
to pointer fields of structures.
compared to the 3rd version:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682310.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682312.html
https://gcc.gnu.org/piper
gcc/c/ChangeLog:
* c-typeck.cc (build_counted_by_ref): Handle pointers with counted_by.
(build_access_with_size_for_counted_by): Likewise.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Handle pointers
with counted_by.
(collect_object
On Mon, 12 May 2025, Tomasz Kamiński wrote:
> Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
> generic
> move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
> move_only_function instantiations, the ownership of the target object is
> direclt
On Mon, 12 May 2025, Tomasz Kamiński wrote:
> The file now includes copyable_function in addition to
> move_only_function.
>
> PR libstdc++/119125
>
> libstdc++-v3/ChangeLog:
> * include/bits/move_only_function.h: Move to...
> * include/bits/funcwrap.h: ...here.
> * doc/d
On 5/13/25 02:22, Tobias Burnus wrote:
Hi Sandra, hello world,
Sandra Loosemore wrote:
I have created the devel/omp/gcc-15 (aka "OG15") branch, ...
For previous branches we'd been using ChangeLog.omp files paralleling
the normal ChangeLog files, that were updated manually and committed
with
Hello GCC Community,
Many years have past since I actively worked on the aarch64 backend, so this
email is long over due. I’ll be leaving Arm shortly so this seems like a good
time to formerly step down as an AArch64 maintainer. It has been a privilege to
contribute to GCC and to work alongside
On 5/13/25 4:29 PM, Ville Voutilainen wrote:
On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
/* Check that the return and argument types are sane before
folding. */
- if (INDIRECT_TYPE_P (TREE_TYPE (x))
- && INDIRECT_TYPE_P (TREE_TYPE (r)))
+
Hello world,
this fixes the other regression which crept in with gfortran.
Again, regression-tested, plus the local testing script is
attached.
Ok for trunk and gcc-15?
Best regards
Thomas
Fix explicit arrays with non-constant size for -fc-prototypes.
gcc/fortran/ChangeLog:
This is the followup mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683444.html .
It adds the check for cfun before accessing function specific flags.
We handle the case where !cfun as conservative in that it the function might
throw.
gcc/ChangeLog:
* gimple-fold.cc (re
On 5/12/25 5:03 PM, Owen Avery wrote:
Please add a little rationale for the change here, perhaps adapting the
one from your previous patch.
gcc/cp/ChangeLog:
* method.cc
(synthesized_method_walk): Check whether -Wvirtual-move-assign
The (function) should usually go on the s
On Tue, 13 May 2025 at 23:34, Jason Merrill wrote:
>
> On 5/13/25 4:29 PM, Ville Voutilainen wrote:
> > On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
> >>>/* Check that the return and argument types are sane before
> >>> folding. */
> >>> - if (INDIRECT_TYP
On 30/04/25 13:23 +0200, Tomasz Kamiński wrote:
This commits adjust the way how the arguments are stored in the _Arg_value
(and thus basic_format_args), by preserving the types of fixed width
floating-point types, that were previously converted to float, double,
long double.
The _Arg_value union
On 5/13/25 10:56 AM, Alejandro Colomar wrote:
Hi Jason,
On Tue, May 13, 2025 at 10:35:00AM -0400, Jason Merrill wrote:
It seems to be one of the more common trailers used in the linux
kernel [1],
Hmm, I don't see it in that list. But it is described in
https://docs.kernel.org/process/submi
Hello world,
the attached patch fixes a 15/16 regression and should be fairly
self-explanatory.
Regarding testing: I'm not sure I am up to the task of hacking
dejagnu to do this. I am now running local tests, which is
better than nothing (I guess).
Regression-testing: Passed, though this does n
Adding link for xref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120264
Thanks, Cassio.
On Mon, 12 May 2025 at 10:06, Jonathan Wakely wrote:
> On Sun, 11 May 2025 at 12:34, Cassio Neri wrote:
> >
> > Hi all,
> >
> > After reflecting on my previous message and Andrew's, I now believe this
> pa
On 5/12/25 4:32 PM, Ville Voutilainen wrote:
This function is yet another stdlib function that is just a simple cast, so
having
it appear while debugging is arguably not useful. So add it to the existing
handling
that always-folds some stdlib functions.
Add std::to_underlying to the set of std
On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
> > /* Check that the return and argument types are sane before
> > folding. */
> > - if (INDIRECT_TYPE_P (TREE_TYPE (x))
> > - && INDIRECT_TYPE_P (TREE_TYPE (r)))
> > + if (id_equal (DECL_NAME (
On Tue, 13 May 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, May 13, 2025 1:59 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [PATCH 1/2]middle-end: Apply loop->unroll directly in
> > vectorizer
> >
> >
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start with: the imported constructor isn't DECL_ONE_ONLY (as its
external) and so 'can_alias_cdtor' returns false.
When moving the optimize_memcpy_to_memset optimization to forwprop from
fold_stmt, the marking
of the bb to purge for eh cleanup was not happening for the local optimizations
but only after
the fold_stmt, this causes g++.dg/torture/except-2.C to fail.
So this patch moves the marking of the bbs fo
This moves the canonicalization of `bool==0` and `bool!=1` from
forwprop to cleanupcfg. We will still need to call it from forwprop
so we don't need to call forwprop a few times to fp comparisons in some
cases (forwprop-16.c was added originally for this code even).
This is the first step in remov
Since the merge of the tuples branch (r0-88576-g726a989a8b74bf), the
if:
```
if (TREE_CODE_CLASS (gimple_cond_code (stmt)) != tcc_comparison)
```
Will always be false so let's change it into an assert.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (forward_propagate_into_gimple_cond): Assert
We have code later on that verifies the code is a comparison. So let's
try to catch it earlier. So it is easier to debug where the incorrect code
gets set.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gimple.h (gimple_cond_set_code): Add assert of the code
being
The Intel Decimal Floating-Point Math Library is available as open-source on
Netlib[1].
[1] https://www.netlib.org/misc/intel/
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
libgcc/config/libbid/ChangeLog:
* bid128_string.c (MIN_DIGITS): New macro.
Update in V3
> > > + cost_sse_integer = 0;
> > > + weighted_cost_sse_integer = 0 ;
> Extra space here.
Changed.
> > > + : ix86_size_cost.sse_to_integer;
>
> Please be sure to not revert the changes from my patch adding
> COSTS_N_INSNS (...) / 2
> here and some other places.
Yes, keep the
On 5/13/25 7:15 PM, Ville Voutilainen wrote:
On Tue, 13 May 2025 at 23:42, Ville Voutilainen
wrote:
It seems to me that this
sanity check is checking that it's a cast between
references for the other ones, and that's just unsuitable for
to_underlying. I would suggest just removing that sanity
On Wed, May 14, 2025 at 9:22 AM liuhongt wrote:
>
> The Intel Decimal Floating-Point Math Library is available as open-source on
> Netlib[1].
>
> [1] https://www.netlib.org/misc/intel/
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ready push to trunk.
>
> libgcc/config/libbid/Ch
On 5/13/25 5:18 PM, Owen Avery wrote:
This patch makes it easier to selectively disable
-Wvirtual-move-assign by allowing diagnostic pragmas on
base class move assignment operators to suppress such
warnings.
Pushed, thanks!
gcc/cp/ChangeLog:
* method.cc (synthesized_method_walk): Che
Adding Eugene and Andi to CC as Sam suggested.
> On 13 May 2025, at 12:57 am, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kugan Vivekanandarajah writes:
>> diff --git a/configure.ac b/configure.ac
>> index 730db3c1402..701284e38f2 100644
>> ---
For a debugger to display statically-allocated[0] TLS variables the compiler
must communicate information[1] that can be used in conjunction with knowledge
of the runtime enviroment[2] to calculate a location for the variable for
each thread. That need gives rise to dw_loc_dtprel in dwarf2out, a fl
On Fri, Apr 18, 2025 at 7:10 PM H.J. Lu wrote:
>
> Add preserve_none attribute which is similar to no_callee_saved_registers
> attribute, except on x86-64, r12, r13, r14, r15, rdi and rsi registers are
Could you split preserve_none into a separate patch,
It looks like it's different from clang's p
On Tue, May 13, 2025 at 10:04 PM Jonathan Wakely wrote:
> On 30/04/25 13:23 +0200, Tomasz Kamiński wrote:
> >This commits adjust the way how the arguments are stored in the _Arg_value
> >(and thus basic_format_args), by preserving the types of fixed width
> >floating-point types, that were previo
On Apr 16, 2025, Alexandre Oliva wrote:
> But I acknowledge that it's a bit of a risky proposition; I suppose it
> would be more conservative to disable it uniformly on all targets, and
> only enable it with -m32 when explicitly requested. I.e., make
> OS_MISSING_POWERPC64 the rule rather than t
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 12:08 PM
> To: Richard Sandiford
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt
> grouping hook
>
> On Tue, 13 May 2025, Richard Sandiford
Hi all,
As mentioned in GCC 15, we will remove -mavx10.1-256/512 and -mno-evex512
options in GCC 16. Also we will do some clean up in code for all the size
happening all together.
The first patch of the patch set removes those options, while the following
four is refactoring and cleaning up for t
On 2025-05-01 2:56 p.m., Bruce McCulloch wrote:
Currently, gen_ctf_base_type will obtain the bit_size of a given DWARF DIE based
on the system GCC is compiling for. For DIEs with a DW_ATE_float encoding, this
is used to determine whether to classify a given DIE as a single, double, or
long double
Hi Thomas,
Same remark as for PR120107! LGTM for both branches.
Thanks
Paul
On Tue, 13 May 2025 at 21:30, Thomas Koenig wrote:
> Hello world,
>
> this fixes the other regression which crept in with gfortran.
> Again, regression-tested, plus the local testing script is
> attached.
>
> Ok for
Hi Tobias,
> Admittedly, this *PING* is rather early – but as more trigonometric
> functions changes are coming, I think it would be useful to agree
> that this is a good approach.
Patch is OK to push.
FX
So it won't do the unsafe truncation for double(1.001) to float(1.0)
since there's precision loss.
It's guarded by testcase pr103771-6.c
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
REAL_CST is handled if it can be represented in different floating
point typ
There are several iterators no longer needed in md files since
after refactor in AVX10, they could directly use legacy AVX512
ones. Remove those duplicate iterators.
gcc/ChangeLog:
* config/i386/sse.md (VF1_VF2_AVX10_2): Removed.
(VF2_AVX10_2): Ditto.
(VI1248_AVX10_2): Dit
> Am 13.05.2025 um 23:24 schrieb Martin Jambor :
>
> Hi,
>
> this patch fixes (hopefully the) one remaining place where gimple SRA
> was still creating a load into a const aggregates. It occurs when
> there was a replacement for a load but that replacement is not type
> compatible - typicall
Hi Thomas,
I don't think that anybody else has been up to the job of hacking dejagnu
to test patches to dump-parse-tree.cc :-)
I think that the patch verges on the 'obvious' and is good for both
15-branch and mainline.
Thanks for the patch.
Paul
On Tue, 13 May 2025 at 21:15, Thomas Koenig wr
> From: Haochen Jiang
> Sent: Wednesday, May 14, 2025 2:17 PM
>
> Hi all,
>
> As mentioned in GCC 15, we will remove -mavx10.1-256/512 and -mno-
> evex512 options in GCC 16. Also we will do some clean up in code for all the
> size happening all together.
>
> The first patch of the patch set rem
101 - 144 of 144 matches
Mail list logo
