er_safety;
using std::get_unexpected;
using std::pointer_safety;
using std::set_unexpected;
using std::undeclare_no_pointers;
using std::undeclare_reachable;
using std::unexpected_handler;
Wonder if they should be exported in C++20 only or kept unexported.
2025-08-04 Jakub Jelinek
PR libstdc++/
quot;" and """" does not give a valid preprocessing token
looked weird and so I've updated the message to use %< and %> instead
of \" quoting.
Ok for trunk?
2025-08-04 Jakub Jelinek
PR preprocessor/120778
* macro.cc (paste_tokens): U
On Mon, Aug 04, 2025 at 03:11:32PM +0200, Jonathan Wakely wrote:
> Somebody submitted patches for those and byteswap in the past 24 hours, but
> your patch is more complete.
I was aware of byteswap but missed the second version of the patch that
added the #if around it; that PR made me look for th
ified it is in
corresponding eel.is/c++-draft/*.syn etc. and looked it up in the libstdc++
headers for guarding macros.
After all the additions I've compiled std.cc with -std=c++20, -std=c++23 and
-std=c++26, the first one revealed std::ranges::shift_{left,right} emitted an
error in that case, the
sing exports (like in PR121373
std::byteswap), maybe one could dig that stuff somehow from the raw
dump (look for identifiers in std namespace (and perhaps inlined namespaces
thereof at least) which don't start with underscore.
Anyway, ok for trunk?
2025-08-02 Jakub Jelinek
* s
-linux and i686-linux, ok for trunk?
Or do you prefer a warning everywhere and just add a testcase?
2025-08-02 Jakub Jelinek
PR preprocessor/120778
* macro.cc (stringify_arg): For C++26 emit a pedarn instead of warning
for \ at the end of stringification.
* g
* macros that aren't guarded on -std= version but say -fmodules,
-fchar8_t, -fcoroutines etc. options) and warn/pedwarn on the libcpp
side even when they aren't defined?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-02 Jakub Jelinek
PR pr
Hi!
The CWG1709 just codifies existing GCC (and clang) behavior, so this
just adds a testcase for that.
Tested on x86_64-linux, ok for trunk?
2025-08-01 Jakub Jelinek
PR preprocessor/120778
* g++.dg/DRs/dr1709.C: New test.
--- gcc/testsuite/g++.dg/DRs/dr1709.C.jj
On Fri, Aug 01, 2025 at 11:39:34AM -0500, Robert Dubner wrote:
> --- a/gcc/cobol/genutil.cc
> +++ b/gcc/cobol/genutil.cc
> @@ -27,6 +27,9 @@
> * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> */
Hi!
Contrary to what the paper says, I think for #line directives we diagnose
everything we should (sure, some diagnostics are pedwarns).
Tested on x86_64-linux, ok for trunk?
2025-08-01 Jakub Jelinek
PR preprocessor/120778
* g++.dg/DRs/dr2580.C: New test.
--- gcc/testsuite
On Thu, Jul 31, 2025 at 10:20:23PM +0200, Jakub Jelinek wrote:
> The following patch introduces a -Wkeyword-macro warning that clang has
> since 2014 to implement part of C++26 P2843R3 Preprocessing is never undefined
> paper.
Here is a tiny change to the patch, added an inline function
nor checked for
that and C23 doesn't have anything like that, so the following testcase
merely tests that we don't diagnose anything on it.
Tested on x86_64-linux, ok for trunk?
2025-08-01 Jakub Jelinek
* c-c++-common/cpp/comment-ff-1.c: New test.
* c-c++-common/cpp/c
On Thu, Jul 31, 2025 at 11:33:07PM +0200, Jakub Jelinek via Gcc wrote:
> > this was all described in excruciating detail in the patch submission
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687385.html
> >
> > and the commit message.
>
&g
On Thu, Jul 24, 2025 at 06:38:26PM +0300, Artemiy Granat wrote:
> gcc/ChangeLog:
>
> * config/i386/i386-options.cc (ix86_handle_cconv_attribute):
> Handle simultaneous use of regparm and thiscall attributes in
> case when regparm is set before thiscall.
>
> gcc/testsuite/ChangeL
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-31 Jakub Jelinek
PR preprocessor/120778
gcc/
* doc/invoke.texi (Wkeyword-macro): Document.
gcc/c-family/
* c.opt (Wkeyword-macro): New option.
* c.opt.urls: Regenerate.
*
ain if the value is the same. So I think better
just return NULL (i.e. punt).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
2025-07-31 Jakub Jelinek
PR middle-end/121322
* gimple-ssa-store-merging.cc (find_bswap_or_nop): Return NUL
t it to peek->type
== CPP_PRAGMA_EOL in the not_module block, then the backup handling can be
shared (attached patch). The second (attached) is certainly shorter.
Both were just tested on the single testcase, which one do you prefer (or
something different)?
2025-07-31 Jakub Jelinek
arguments
also HOST_WIDE_INT.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/15.2?
2025-07-31 Jakub Jelinek
PR tree-optimization/121264
* machmode.h (get_best_mode): Change type of first 2 arguments
from int to HOST_WIDE_INT.
* stor-
Hi!
I've committed following patch as obvious.
2025-07-31 Jakub Jelinek
* gimple-ssa-store-merging.cc (find_bswap_or_nop): Fix comment typos,
hanlde -> handle.
* config/i386/i386.cc (ix86_gimple_fold_builtin, ix86_rtx_costs):
Likewise.
* con
On Fri, Jul 25, 2025 at 07:51:41PM +0100, Sam James wrote:
> Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9.
>
> The termio ioctls are no longer used after commit 59978b21ad9c
> ("[sanitizer_common] Remove interceptors for deprecated struct termio
> (#137403)"), remove the
On Wed, Jul 30, 2025 at 06:52:40PM +0800, Yang Yujie wrote:
> I'm OK with your implementation. Just curious, do you mean that
> memcmp shouldn't be used on "(x)" at all?
If there are any padding bits with undefined values, yes.
So, e.g. don't use memcmp on addresses of _BitInt vars on
x86_64/i686
On Wed, Jul 30, 2025 at 06:24:42PM +0800, Yang Yujie wrote:
> On Wed, Jul 30, 2025 at 12:19:24PM GMT, Jakub Jelinek wrote:
> > On Wed, Jul 30, 2025 at 06:15:56PM +0800, Yang Yujie wrote:
> > > So wouldn't it be simpler if I just change the comparison in my patch into
>
On Wed, Jul 30, 2025 at 06:15:56PM +0800, Yang Yujie wrote:
> So wouldn't it be simpler if I just change the comparison in my patch into
> a memcmp? This works regardless of how comparison is implemented.
> (We all assume that expression (x) may have its address taken.)
No. memcmp after memcpy w
On Wed, Jul 30, 2025 at 04:56:06PM +0800, Yang Yujie wrote:
> I'm not sure if this is correct, but isn't accessing __x in its own type
> after do_copy already an undefined behavior?
>
> N3301 J.2 (34)
> > An object has its stored value accessed other than by an lvalue of
> > an allowable type (6.
On Wed, Jul 30, 2025 at 10:17:43AM +0200, Jakub Jelinek wrote:
> On Wed, Jul 30, 2025 at 10:16:06AM +0200, Jakub Jelinek wrote:
> > Or maybe better
> > _BitInt(PROMOTED_SIZE (x) * __CHAR_BIT__) __x;
> > int __y = S (x);
> > do_copy (&__x, &(x), sizeof (__x)
On Wed, Jul 30, 2025 at 10:16:06AM +0200, Jakub Jelinek wrote:
> Or maybe better
> _BitInt(PROMOTED_SIZE (x) * __CHAR_BIT__) __x;
> int __y = S (x);
> do_copy (&__x, &(x), sizeof (__x));
> if (__y < PROMOTED_SIZE (x) * __CHAR_BIT__)
> {
>
On Wed, Jul 30, 2025 at 09:37:10AM +0200, Jakub Jelinek wrote:
> On Fri, Jul 25, 2025 at 10:53:39AM +0800, Yang Yujie wrote:
> > In BEXTC, whether a _BitInt object is properly extended is examined
> > by a value comparison against a copied object in a wider _BitInt
> > type
On Wed, Jul 30, 2025 at 03:44:16PM +0800, Yang Yujie wrote:
> On Wed, Jul 30, 2025 at 09:29:49AM GMT, Jakub Jelinek wrote:
> > On Fri, Jul 25, 2025 at 10:53:37AM +0800, Yang Yujie wrote:
> > > +
> > >addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (var));
> > >
On Fri, Jul 25, 2025 at 10:55:36AM +0800, Yang Yujie wrote:
> This patch adds support for C23's _BitInt for LoongArch.
>
> >From the LoongArch psABI[1]:
>
> > _BitInt(N) objects are stored in little-endian order in memory
> > and are signed by default.
> >
> > For N ≤ 64, a _BitInt(N) object have
On Fri, Jul 25, 2025 at 10:53:41AM +0800, Yang Yujie wrote:
> libgcc/ChangeLog:
>
> * config.host: Remove unused code. Include LoongArch-specific
> tmake_files after the OS-specific ones.
Here you want loongarch maitainer review.
Jakub
On Fri, Jul 25, 2025 at 10:53:40AM +0800, Yang Yujie wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/bitint-84.c
> @@ -0,0 +1,19 @@
> +/* A simple variant of gcc.dg/torture/bitint-64.c */
> +/* { dg-do run { target bitint } } */
> +/* { dg-options "-std=c23 -fwrapv" } */
> +/* { dg-skip
On Fri, Jul 25, 2025 at 10:53:38AM +0800, Yang Yujie wrote:
> A widening cast from a signed _BitInt operand to an unsigned _BitInt
> type involves filling the extra limb(s) with sign extension.
> On a target that wants _BitInts extended in memory, if this unsigned
> type has a partial limb, the unu
On Fri, Jul 25, 2025 at 10:53:39AM +0800, Yang Yujie wrote:
> In BEXTC, whether a _BitInt object is properly extended is examined
> by a value comparison against a copied object in a wider _BitInt
> type that utilizes all of the partial limb.
>
> Since the (implicit) conversion to the wider type m
On Fri, Jul 25, 2025 at 10:53:37AM +0800, Yang Yujie wrote:
> This patch also make casts of ABI-extended large/huge _BitInts
> behave the same as the small/middle case, i.e. no-op for casts
> to a higher precision _BitInt with the same number of limbs /
> extension for casts that turns a full top l
On Fri, Jul 25, 2025 at 10:53:36AM +0800, Yang Yujie wrote:
> P.S. For encoding this test as well as type-generic programming,
> it would be nice to have a builtin function to obtain "N" at
> compile time from _BitInt(N)-typed expressions. But here
> we stick to existing ones (__builtin_clrsbg / _
On Fri, Jul 25, 2025 at 10:53:35AM +0800, Yang Yujie wrote:
> For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
> we assume small _BitInts to be internally extended after arithmetic
> operations. In this case, an extra extension during RTL expansion
> can be avoided.
>
> gcc/C
On Fri, Jul 25, 2025 at 10:53:34AM +0800, Yang Yujie wrote:
> For targets that treat small _BitInts like the fundamental
> integral types, we should allow their machine modes to be promoted
> in the same way.
>
> gcc/ChangeLog:
>
> * explow.cc (promote_function_mode): Add a case for
>
On Tue, Jul 29, 2025 at 11:20:25AM -0500, Robert Dubner wrote:
> I removed the pick of 0eac9cfe, and I removed the pick of ed8761241ac529,
> which had already been done by Thomas.
>
> I just applied the other 45 relevant commits, and pushed that.
Great, thanks.
git diff
r15-10108-g50c91681558e4
On Tue, Jul 29, 2025 at 11:02:08AM -0400, Hans-Peter Nilsson wrote:
> > If you have a target with bogus MAX_FIXED_MODE_SIZE definition, you should
> > just fix that.
>
> That macro should be avoided, for one because it's misleading
> and ends up being used for other than target tweaking (QED).
N
On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> }
>
> RT (t->function_decl.personality);
> - RT (t->function_decl.function_specific_target);
> - RT (t->function_decl.function_specific_optimization);
> +
d i686-linux, ok for trunk?
BTW, I wonder if anything in the standard disallows <=> in the preprocessor
expressions. Say
#if (0 <=> 1) < 0
etc.
#include
constexpr int a = (0 <=> 1) < 0;
is valid (but not valid without #include ) and the expressions
don't use any
that).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer a solution closer to the C FE, cp_parser_extension_opt
saving the values into a bitfield and have another function to restore
the state (or use RAII)?
2025-07-29 Jakub Jelinek
PR c++/1
On Tue, Jul 29, 2025 at 08:55:05AM +0200, Richard Biener wrote:
> > The result of that is the branch "patched15". It has 47 cherry-picked
> > commits on top of gcc/releases/gcc-15. With gcc-15.1.0 as the compiler,
> > it successfully compiles on an x86_64-linux Ubuntu 22.04 LTS system
> > startin
ns noreturn as well, it has no other meaning.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/15.2?
2025-07-29 Jakub Jelinek
PR middle-end/121159
* calls.cc (can_implement_as_sibling_call_p): Don't reject declared
noreturn function
On Sat, Jul 26, 2025 at 10:37:35AM -0700, H.J. Lu wrote:
> __tls_get_addr doesn't preserve vector registers. When a function
> with no_caller_saved_registers attribute calls __tls_get_addr, YMM
> and ZMM registers will be clobbered. Issue an error and suggest
> -mtls-dialect=gnu2 in this case.
>
On Wed, Jul 23, 2025 at 05:59:22PM +, Qing Zhao wrote:
> struct S {
> int n;
> int *p __attribute__((counted_by(n)));
> } *f;
> Int *g;
> void setup (int **ptr, int count)
> {
> *ptr = __builtin_malloc (sizeof (int) * count);
> g = *ptr;
> };
> int main ()
> {
> f = __builtin_malloc (si
On Fri, Jul 25, 2025 at 07:51:41PM +0100, Sam James wrote:
> Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9.
I thought it got reverted on the glibc side:
https://sourceware.org/git/?p=glibc.git;a=commit;h=0f93d54cde08d1da321493b999d6833779995a86
Jakub
On Sun, Jul 27, 2025 at 09:27:30PM -0400, Pietro Monteiro wrote:
> On Mon, Jul 14, 2025, at 10:43 PM, Hans-Peter Nilsson wrote:
> > Tested to fix build for MMIX (and to fix a few type-generic-builtin
> > test-cases; c-c++-common/pr111309-1.c, gcc.dg/torture/pr116480-1.c).
> > Also regtested cris-el
Hi!
I'd like to ping 2 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682373.html
- PR117783 - c++: Implement C++26 P1061R10 - Structured Bindings can
introduce a Pack
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687935.html
- PR120845 - libcpp: Fi
appends some further
entities to the FIXME list, those all seems to be unimplemented yet.
Tested on x86_64-linux, ok for trunk?
2025-07-19 Jakub Jelinek
PR libstdc++/121174
* src/c++23/std.cc.in (std::dextents): Export. Add to FIXME comments
other not yet implemented nor
On Fri, Jul 18, 2025 at 09:07:35AM +0200, Richard Biener wrote:
> The PR shows that the uninit analysis limits are set too low in
> cases we lower switches to ifs as happens on s390x for a linux
> kernel TU. This causes false positive uninit diagnostics as we
> abort the attempt to prove that a va
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
> Hmm, perhaps, for stateful evaluation like define_aggregate. But we could
> address that with a flag on the STATIC_ASSERT like this patch puts on the
> STMT_EXPR.
Sure.
Jakub
On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
> On 7/16/25 10:49 AM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This patch implements consteval blocks, as specified by P2996.
> > They aren't very useful without define
.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/15.2/14.4?
2025-07-17 Jakub Jelinek
PR tree-optimization/121131
* gimple-fold.cc (fold_nonarray_ctor_reference): Use
TREE_INT_CST_LOW (TYPE_SIZE ()) instead of
GET_MODE_BITSIZE (SCALAR_INT_TYPE_MODE
On Thu, Jul 17, 2025 at 03:26:05PM +, Qing Zhao wrote:
> How about add a new flag to distinguish these two cases, and put it to the
> 3th argument:
>
>ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE,
> TYPE_OF_SIZE + ACCESS_MODE + IS_POINTER, TYPE_SIZE_UNIT
> for element)
On Thu, Jul 17, 2025 at 03:31:57PM +0200, Tomasz Kamiński wrote:
> From: Jonathan Wakely
>
> Implement std::inplace_vector as specified in P0843R14, without follow
> up papers, in particular P3074R7 (trivial unions). In consequence
I think implementation of that paper is waiting mainly for
https
On Wed, Jul 16, 2025 at 09:22:19PM +, Qing Zhao wrote:
> Yes, the above solution could also resolve the undefined behavior issue. We
> can certainly go
> with this approach.
Another option is to use .ACCESS_WITH_SIZE (with different flags compared to
the FAM cases) solely on reads from the
On Tue, Jul 15, 2025 at 06:39:42PM +, Qing Zhao wrote:
> I re-implemented the patch based on B to fix PR120929, however, the approach
> B brings undefined behavior into the application.
>
> (Actually, I met this issue in the previous implementation but forgot to
> documented it.
> This iss
pret_cast not being valid during constant evaluation
time.
So, this patch just tests non-array std::relocate at both runtime and
constexpr time, everything else at runtime only.
2025-07-16 Jakub Jelinek
PR c++/119064
* include/bits/version.def (trivially_relocatable):
_error/* 19_diagnostics/logic_error/*
19_diagnostics/headers/stdexcept/* 20_util/expected/* 20_util/variant/*
20_util/optional/*'"
2025-07-16 Jakub Jelinek
* include/bits/version.def: Implement C++26 P3378R2 - constexpr
exception types.
(constexpr_exceptio
On Tue, Jul 15, 2025 at 09:02:09AM -0700, Andrew Pinski wrote:
> For aarch64, libgcc is built with -Werror, after the latest
> -Wunused-but-set* commit (r16-2258-g0eac9cfee8cb0b21d), a new warning
> showed up:
> ```
> ../../../gcc/libgcc/config/libbid/bid_binarydecimal.c: In function
> ‘__binary32_
On Tue, Jul 15, 2025 at 08:36:46AM -0700, Andrew Pinski wrote:
> On Tue, Jul 15, 2025 at 6:06 AM Jakub Jelinek wrote:
> >
> > On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> > > Given the above that seems rather unlikely, but I suppose it's fine if
On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> Given the above that seems rather unlikely, but I suppose it's fine if you
> want to do it that way. The patch is OK either way.
Committed just the v2 patch. I can test your patch next with other patches,
or do you want to test/com
On Tue, Jul 15, 2025 at 08:30:33AM -0400, Jason Merrill wrote:
> > The diagnostic only changed for C++26, and I'm not sure why (the _S_at
> > function isn't constexpr, so why wasn't it failing there before?)
>
> In C++23, we could see that the outermost thing in the expression is a call
> to _M_er
On Mon, Jul 14, 2025 at 11:58:32PM -0400, Jason Merrill wrote:
> Coming back to this comment, it still seems to me that we can generalize
> this and ignore anything cast to void here, as in the below; after something
> has been cast to void, it can no longer be read. I don't get any
> regressions
expr (and cp_build_unary_op), so your
simplification of cp_fold is ok and doesn't regress anything.
Here is an updated patch, with your cp_fold change, and different
finish_unary_op_expr change.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-14 Jakub Jelinek
On Mon, Jul 14, 2025 at 12:11:18PM +0200, Tomasz Kaminski wrote:
> > + if (__builtin_expect(__fwd, true))
> >
> We have a preference to use [[likely]] attribute when possible.
Ok, changed to
if (__fwd) [[likely]]
in my copy.
>
> > + {
> > + for (; __first != __last; ++__
On Fri, Jul 11, 2025 at 03:12:44PM +0100, Jonathan Wakely wrote:
> The if-consteval branches in std::make_exception_ptr and
> std::exception_ptr_cast use a try-catch block, which gives an error for
> -fno-exceptions. Just make them return a null pointer at compile-time
> when -fno-exceptions is use
On Sun, Jul 13, 2025 at 05:28:21PM +0100, Jonathan Wakely wrote:
> ---
>
> This is an anachronism: ChangeLog entries should never be part of the
> patch, because nobody should be editing them locally and including them
> in a commit. Whether you can self-approve or not isn't relevant.
>
> OK for
On Fri, Jul 11, 2025 at 02:34:24PM -0400, Jason Merrill wrote:
> But by the time we get to cp_fold, DECL_READ_P should have already been set
> appropriately when we built the thing we're now folding. And calling
Clearly it hasn't been, otherwise I'd need to patch different spots as well.
> mark_
On Fri, Jul 11, 2025 at 12:26:54PM -0400, Jason Merrill wrote:
> On 7/11/25 9:09 AM, Jakub Jelinek wrote:
> > On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
> > > > --- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
> > > > +++ gc
Hi!
On Tue, Jun 17, 2025 at 01:14:03PM +0200, Jakub Jelinek wrote:
> Here is a new version of the library side of the C++26 P2786R13 paper.
> For if constexpr the patch uses __builtin_constant_p trick to figure
> out if __result is non-equality comparable with __first, it adds recursion
On Fri, Jul 11, 2025 at 02:26:28PM +0100, Jonathan Wakely wrote:
> On Fri, 11 Jul 2025 at 14:19, Jakub Jelinek wrote:
> >
> > On Fri, Jul 11, 2025 at 01:47:18PM +0100, Jonathan Wakely wrote:
> > Thanks for doing this.
> >
> > > @@ -301,8 +301,9 @@ names
On Fri, Jul 11, 2025 at 01:47:18PM +0100, Jonathan Wakely wrote:
Thanks for doing this.
> @@ -301,8 +301,9 @@ namespace std _GLIBCXX_VISIBILITY(default)
> _GLIBCXX26_CONSTEXPR exception_ptr
> make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
> {
> -#if __cplusplus >= 202400L
> +#if
On Fri, Jul 11, 2025 at 02:11:05PM +0100, Jonathan Wakely wrote:
> On Fri, 11 Jul 2025 at 14:02, Jonathan Wakely wrote:
> >
> > The if-consteval branches in std::make_exception_ptr and
> > std::exception_ptr_cast use a try-catch block, which gives an error for
> > -fno-exceptions. Just make them r
On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
> > --- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
> > +++ gcc/cp/cp-gimplify.cc 2025-04-23 21:33:19.050931604 +0200
> > @@ -3200,7 +3200,23 @@ cp_fold (tree x, fold_flags_t flags)
> > loc = EXPR_LOCAT
Hi!
This was a regression introduced by r16-1893 (and its backports) for C++,
though for C it had false positive warning for years. Fixed by r16-2000
(and its backports).
Tested on x86_64-linux, committed to trunk as obvious.
2025-07-11 Jakub Jelinek
PR c++/120954
* c-c
for trunk/15.2?
2025-07-11 Jakub Jelinek
Martin Jambor
PR ipa/121023
* ipa-fnsummary.cc (compute_fn_summary): Disallow signature changes
on cfun->has_musttail functions.
* c-c++-common/musttail32.c: New test.
--- gcc/ipa-fnsummary.cc.jj 2
p;& (type_memfn_quals (type) == TYPE_UNQUALIFIED
> > + && type_memfn_rqual (type) == REF_QUAL_NONE)));
>
> The inner parens seem redundant.
I was just moving the function earlier. Anyway, changed.
So far lightly tested, can bootstrap/regtest it overnight.
2
On Thu, Jul 10, 2025 at 05:49:53PM +, Qing Zhao wrote:
> One more note here, previously, ACCESS_MODE has 5 values:
> -1: Unknown access semantics
> 0: none
> 1: read_only
> 2: write_only
> 3: read_write
>
> For counted_by, I passed “-1” to the .ACCESS_WITH_SIZE.
>
On Thu, Jul 10, 2025 at 05:27:50PM +, Qing Zhao wrote:
> ACCESS_MODE is only for a future work to reimplement the attribute
> access with the internal function .ACCESS_WITH_SIZE.
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute
>
> For th
On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position
> of the arguments per the new design.
>
> gcc/c/ChangeLog:
>
> * c-typeck.cc (build_counted_by_ref): Update comments.
>
On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote:
> The size of the element of the FAM _cannot_ reliably depends on the original
> TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE:
>
> TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5
>
>
On Thu, Jul 10, 2025 at 07:26:52AM +, Kyrylo Tkachov wrote:
> … “Tunning” looks like a typo as well, should likely be “Tuning”.
You're right, but because like often it occurs in another place as well,
I've committed this separately as obvious.
Thanks for finding this.
2025
Hi!
While I'm not a native English speaker, I believe all the uses
of bellow (roar/bark/...) in comments in gcc are meant to be
below (beneath/under/...).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-10 Jakub Jelinek
gcc/
* tree-vect-lo
On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote:
Thanks for the review.
Working on the rest (most of it already have in my working copy).
> > case CLEANUP_POINT_EXPR:
> > {
> > - auto_vec cleanups;
> > + auto_vec cleanups;
>
> What's the rationale for this increase
On Tue, Jul 08, 2025 at 11:54:23PM -0600, Alex (Waffl3x) wrote:
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -571,6 +571,15 @@ extern void omp_clause_range_check_failed (const_tree,
> const char *, int,
>TREE_CHECK6 (T, INTEGER_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE, REAL_TYPE,
> \
>
On Tue, Jul 08, 2025 at 03:17:39PM +0200, Richard Biener wrote:
> The following avoids inlining the actual main() (renamed to
> guality_main) into the guality plumbing. This can cause
> jump threading opportunities to appear and generally increase
> the chance what we actually test isn't what we t
On Tue, Jul 08, 2025 at 08:15:30AM +0200, Richard Biener wrote:
> > No. Because (most of the) pointer conversions are useless, if you have
> > _2 = &something.fam[0];
> > ...
> > _4 = &something.fam;
> > _5 = .ACCESS_WITH_SIZE (_4, ...);
> > (or whatever else where _4 has the carefully chosen p
On Mon, Jul 07, 2025 at 07:51:52PM -0400, Siddhesh Poyarekar wrote:
> On 2025-07-07 17:47, Jakub Jelinek wrote:
> > Even 6 arguments is IMHO too much.
> > /* Expand the IFN_ACCESS_WITH_SIZE function:
> > ACCESS_WITH_SIZE (REF_TO_OBJ, REF_T
On Mon, Jul 07, 2025 at 09:18:53PM +, Qing Zhao wrote:
> From OLD:
>
> _2 = &a->c;
> _3 = &a->count;
> _1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
> _4 = *_1;
> D.2964 = __builtin_dynamic_object_size (_4, 1);
>
> To NEW:
>
> _2 = a->c;
> _3 = &a->count;
> _1 = .ACCESS_WITH_SIZE (_
On Mon, Jul 07, 2025 at 11:59:48AM -0400, Jason Merrill wrote:
> > Another case are targets with implicit -fno-delete-null-pointer-checks or
> > when users use that explicitly. In that case one variable or function can
> > actually end up being at address 0, so am not sure if it is correct to
> >
On Thu, Jul 03, 2025 at 09:35:49AM -0400, Jason Merrill wrote:
> On 7/2/25 7:58 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > Here the flag -fno-delete-null-pointer-checks causes the trivial address
> > co
On Mon, Jul 07, 2025 at 09:07:14AM -0400, Siddhesh Poyarekar wrote:
> On 2025-07-07 08:48, Jakub Jelinek wrote:
> > > The return value of .ACCESS_WITH_SIZE clobbering PTR (that subsequently
> > > gets
> > > passed to __builtin_dynamic_object_size) should be suffici
On Mon, Jul 07, 2025 at 07:21:26AM -0400, Siddhesh Poyarekar wrote:
> > is .ACCESS_WITH_SIZE documented? I can't find it documented in the
> > internals manual, internal-fn.def has
>
> It's documented in tree-object-size.cc as:
>
> /* Compute __builtin_object_size for a CALL to .ACCESS_WITH_SIZE
On Sat, Jul 05, 2025 at 08:46:31AM -0400, Jason Merrill wrote:
> I think we want these diagnostics enabled by default; I don't feel strongly
> about unconditional pedwarn vs. permerror.
So like this then?
2025-07-05 Jakub Jelinek
PR c++/84009
so that in the future
we don't need to differentiate it between range for and expansion
statements.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-05 Jakub Jelinek
PR c++/84009
* parser.cc (cp_parser_decomposition_declaration): Ped
Hi!
No idea how this slipped in, I'm terribly sorry.
Strangely nothing in the testsuite has caught this, so I've added
a new test for that.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
and for 15.2, 14.4, 13.4 and 12.5.
2025-07-03 Jakub Jelinek
On Thu, Jul 03, 2025 at 08:12:22PM +0200, Richard Biener wrote:
> > So, instead at least for now, the following patch keeps doing the
> > optimization, just doesn't perform it in pointer arithmetics.
> > pointer_int_sum itself actually adds the multiplication by size_exp,
> > so ptr + expr is turne
- cst)
into
ptr p+ ((sizetype)expr * size_exp +- (sizetype)cst * size_exp)
and
ptr - (expr +- cst)
into
ptr p+ -((sizetype)expr * size_exp +- (sizetype)cst * size_exp)
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-03 Jakub Jelinek
PR c/12083
1 - 100 of 2538 matches
Mail list logo
