tics printout as well, we don't need to print separate info
for each of the freelist, previously we were emitting just one.
Bootstrapped/regtested on x86_64-linux and i686-linux plus additionally
tested with non-bootstrap build with #undef USING_MMAP + make check-gcc,
ok for trunk?
On Wed, May 28, 2025 at 10:44:20AM +0800, Haochen Jiang wrote:
> gcc/ChangeLog:
>
> * doc/extend.texi (C Extensions): Add missing menu items.
> ---
> gcc/doc/extend.texi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index edd3a0d96c5..
On Tue, May 27, 2025 at 11:15:14PM +0200, Alejandro Colomar wrote:
> Oopsy! Sorry! Please fix, yep, it's a pasto. :)
Committed as obvious to trunk:
2025-05-27 Jakub Jelinek
PR c/117025
* c-parser.cc (c_parser_sizeof_or_countof_expression): Use
C2Y rather
On Tue, May 27, 2025 at 08:22:28PM +, Joseph Myers wrote:
> Thanks, I've committed these patches, with additional commit message
> changes to reference PR117025 in the standard way for GCC so that Bugzilla
> picks up the commits automatically.
--- a/gcc/c/c-parser.cc
On Tue, May 27, 2025 at 02:25:14PM +0200, Richard Biener wrote:
> Isn't soft-fp imported from glibc?
Most of it, yes.
Though, the _BitInt specific stuff in there (whether
binary float <-> _BitInt or decimal float <-> _BitInt) is not owned
by glibc, it is an implementation detail of GCC, put into t
On Fri, May 23, 2025 at 01:40:20PM +0200, Richard Biener wrote:
> On Fri, 23 May 2025, Richard Biener wrote:
>
> > The following makes update_web_docs_git work on branches without
> > libgdiagnostic.
> >
> > I'm re-running update_web_docs_git with this, OK if it succeeds now?
>
> One more bit, t
On Fri, May 23, 2025 at 01:34:35PM +0200, Richard Biener wrote:
> The following makes update_web_docs_git work on branches without
> libgdiagnostic.
>
> I'm re-running update_web_docs_git with this, OK if it succeeds now?
>
> Thanks,
> Richard.
>
> maintainer_scripts/
> * update_web_docs_g
On Fri, May 23, 2025 at 11:10:46AM +0200, Tobias Burnus wrote:
> OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]
>
> PR c++/120413
>
> gcc/cp/ChangeLog:
>
> * semantics.cc (finish_omp_target_clauses_r): Handle
> BIND_EXPR with empty BIND_EXPR_BLOCK.
>
On Thu, May 22, 2025 at 11:19:25AM +0200, Tomasz Kamiński wrote:
> From: Jonathan Wakely
>
> This papers implements C++27 std::indirect as specified
s/27/26/
> in P3019 with ammendment to move assgiment from LWG 4251.
s/assgiment/assignment/
Jakub
On Wed, May 21, 2025 at 12:48:21PM +0200, Jakub Jelinek wrote:
> 2025-05-21 Jakub Jelinek
>
> * gimple-lower-bitint.cc (bitint_extended): New variable.
> (bitint_large_huge::lower_shift_stmt): For LSHIFT_EXPR with
> bitint_extended if lhs has most significa
On Wed, May 21, 2025 at 11:44:42PM +0200, Alejandro Colomar wrote:
> Does this sound good?
>
> diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc
> index faa03c4903a2..733cb312341e 100644
> --- i/gcc/c/c-parser.cc
> +++ w/gcc/c/c-parser.cc
> @@ -78,16 +78,6 @@ along w
On Wed, May 21, 2025 at 11:31:01PM +0200, Alejandro Colomar wrote:
> The preexisting ones are not just the outermost ones. The preexisting
> code was
>
> (in_sizeof
>? "sizeof"
>: (in_typeof ? "typeof" : "alignof")));
>
> The only pattern I can find
On Wed, May 21, 2025 at 11:01:38PM +0200, Alejandro Colomar wrote:
> It has been standardized in C2y.
>
> gcc/c/ChangeLog:
>
> * c-parser.cc (c_parser_sizeof_or_countof_expression):
> Add -Wpedantic diagnostic for _Countof in <= C23 mode.
>
> gcc/testsuite/ChangeLog:
>
> * gcc
On Wed, May 21, 2025 at 11:01:31PM +0200, Alejandro Colomar wrote:
> This operator is similar to sizeof but can only be applied to an array,
> and returns its number of elements.
>
> FUTURE DIRECTIONS:
>
> - We should make it work with array parameters to functions,
>and somehow magically re
On Wed, May 21, 2025 at 11:01:35PM +0200, Alejandro Colomar wrote:
> gcc/ChangeLog:
>
> * Makefile.in (USER_H): Add .
> * ginclude/stdcountof.h: Add countof macro.
This one is actually : New file.
If the header existed before and you've just added countof macro
definition, it would be
On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:
> On 21/05/2025 12:26, Christopher Bazley wrote:
> > Hi Joseph,
> >
> > Thanks for reviewing my patch.
> >
> > On 20/05/2025 18:02, Joseph Myers wrote:
> > > On Tue, 20 May 2025, Christopher Bazley wrote:
> > >
> > > > + if (
(if it passes bootstrap/regtest)?
Note, I'm using "n" rather than "" constraints, because with "e" we could
get into trouble when the non-negated value would match endbr{64,32} - the
predicate only checks (I think that is desirable) that the negation isn&
On Wed, May 21, 2025 at 11:48:08AM +0200, Jakub Jelinek wrote:
> With the following patch instead the test finally FAILs on s390x with -O1
> and higher, which shows that left shifts really need special casing for
> info->extended.
> I don't have proof of anything else though.
ly necessary and where those
optimizations can cause further needs to extend at some other places.
2025-05-21 Jakub Jelinek
* gcc.dg/bitintext.h: New file.
* gcc.dg/torture/bitint-82.c: New test.
--- gcc/testsuite/gcc.dg/bitintext.h.jj 2025-05-20 22:39:28.647171638 +0200
+++ gc
On Wed, May 21, 2025 at 09:21:40AM +0200, Jakub Jelinek wrote:
> On Wed, May 21, 2025 at 10:13:27AM +0800, Yang Yujie wrote:
> > On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> > > I'd suggest working on it incrementally rather than with a full patch set.
&
6-linux, ok for trunk?
2025-05-20 Jakub Jelinek
PR target/120360
* config/i386/i386.md (*cmp_plus_1): New pattern.
* gcc.target/i386/pr120360.c: New test.
--- gcc/config/i386/i386.md.jj 2025-05-20 08:14:05.036425035 +0200
+++ gcc/config/i386/i386.md 2025-05-20 20:
On Wed, May 21, 2025 at 10:13:27AM +0800, Yang Yujie wrote:
> On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> > I'd suggest working on it incrementally rather than with a full patch set.
> > In one or multiple patches handle the promote_mode stuff, the atom
On Tue, May 20, 2025 at 11:44:43PM +0200, Alejandro Colomar wrote:
> Hi Jakub,
>
> On Tue, May 20, 2025 at 11:20:27PM +0200, Jakub Jelinek wrote:
> > On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote:
> > > Okay; how about this?
> > >
On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote:
> Okay; how about this?
>
> gcc/c-family/ChangeLog:
>
> * c-common.h: Add _Countof operator.
> * c-common.def: Likewise.
> * c-common.cc (c_countof_type): Likewise.
No, that doesn't des
On Tue, May 20, 2025 at 03:44:09PM +0200, Jakub Jelinek wrote:
> The tests weren't included :(.
I'd like to see something along the lines of following as the test(s)
for the padding bits (if LoongArch will really have the weirdo psABI
then with some special version of that for it).
On Tue, May 20, 2025 at 05:15:33PM +0200, Alejandro Colomar wrote:
> I've based on gnulib commits, which I believe follow the same
> guidelines. For example:
>
> commit 6608062398ef4c983a58b90a1520c39f12fb7ac1
> Author: Paul Eggert
> Date: Fri Jan 10 10:34:58 2025 -0800
>
>
On Tue, May 20, 2025 at 08:58:18PM +0800, Yang Yujie wrote:
> Thanks for the quick review.
>
> Aside from code formatting issues, can I conclude that you suggest
> we should rebase this onto your new big-endian support patch? Or
> do you think it's necessary to add big-endian && extended support
but don't understand paying
extra 4 * 8 * 1000 bytes (+ 6 * 1000 bytes for b2d not using ushort)
just to avoid shifts.
Tested on x86_64-linux, i686-linux and s390x-linux with
make check-gcc dfp.exp
ok for trunk?
2025-05-20 Jakub Jelinek
* config/t-softfp (softfp_bi
On Tue, May 20, 2025 at 11:29:12AM +0800, Yang Yujie wrote:
> This patch adds support for C23's _BitInt for LoongArch.
>
> Though there's not an official psABI definition, our plan
> is to have 16-byte alignment for N > 64 and the padding bits
> sign/zero-extended when passed between procedures.
>
On Tue, May 20, 2025 at 11:29:10AM +0800, Yang Yujie wrote:
> gcc/c-family/ChangeLog:
>
> * c-common.cc (resolve_overloaded_atomic_exchange): Truncate
> _BitInt values before atomic store.
You aren't truncating _BitInt values before atomic store, you are extending
them.
> (reso
On Tue, May 20, 2025 at 11:29:09AM +0800, Yang Yujie wrote:
> Hi,
>
> This is a proposition of a _BitInt(N) implementation for LoongArch,
> with the following psABI description:
>
> ```
> === Fundamental types of N-bit integers
>
> `_BitInt(N)` (as proposed in ISO/IEC WG14 N2763) is a family of
On Tue, May 20, 2025 at 11:29:11AM +0800, Yang Yujie wrote:
> gcc/ChangeLog:
>
> * stor-layout.cc (layout_type): Allow limb_mode to be DImode
> while abi_limb_mode is TImode for _BitInt(N), N > 64.
> ---
> gcc/stor-layout.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
(-m32/-m64, with all bitint related tests, both
normally and --target_board=unix/-shared-libgcc, additionally compared
abilists of libgcc before/after), ok for trunk?
2025-05-20 Jakub Jelinek
* libgcc-std.ver.in (GCC_14.0.0): Remove bitint related exports
from here.
* c
_PRECISION, build_nonstandard_integer_type won't really work on it.
The patch fixes it similarly what has been done for GCC 14 in various
other spots.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-05-19 Jakub Jelinek
* tree-chrec.cc (convert_affine_scev): Use signed_type
e returned precision.
Bootstrapped/regtested on x86_64-linux and i686-linux (where it
doesn't do anything) and tested with all the _BitInt related
tests on s390x-linux, ok for trunk?
2025-05-19 Jakub Jelinek
* libgcc2.c (bitint_reduce_prec): For big endian
__LIBGCC_BITINT_O
On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote:
> If approved, I suggest committing this foundational change first. Constant
> folding for these builtins will be addressed in subsequent patches.
Note, not just constant folding is needed, but I think the builtins should
be handled in
tree-
On Wed, May 14, 2025 at 09:31:59PM +0100, Jonathan Wakely wrote:
> The timeline hasn't shown any tentative dates for future releases since
> 2006-03-06 when GCC 3.4.6 was released and the tentative date got
> replaced with the real date. Since then only actual release dates have
> been added, on th
On Tue, May 13, 2025 at 10:40:16AM +, Tamar Christina wrote:
> That's true. The names are already optional, I can just drop the "requested"
> all together.
>
> I'll give it a few to give others a chance to commit and I'll respin dropping
> "requested"
Is the intended behavior of the "weak"
stcase fails under valgrind without the libgfortran changes and
succeeds with those.
Tested on x86_64-linux and i686-linux, ok for trunk?
2025-05-13 Jakub Jelinek
PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather than
i >=
obably not worth it. */
dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.
Tested on x86_64-linux and i686-linux, ok for trunk?
2025-05-12 Jakub Jelinek
frequently used path so probably not worth it. */
dest -= dstride[n] * extent[n];
So, I believe the easiest fix would be to somehow arrange for the
" * string_len" subtrings to be omitted twice, but am not sure where and
how.
2025-05-12 Jakub Jelinek
PR fortran/12
ibrary side, so I'll post it incrementally.
2025-05-12 Jakub Jelinek
Daniil Kochergin
Tobias Burnus
PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actua
On Fri, May 09, 2025 at 09:32:50PM +0200, Alejandro Colomar wrote:
> gcc/ChangeLog:
>
> * Makefile.in
Missing (USER_H): Add stdcountof.h.
> --- /dev/null
> +++ b/gcc/ginclude/stdcountof.h
> @@ -0,0 +1,31 @@
> +/* Copyright (C) 2025 Free Software Foundation, Inc.
> +
> +This file is part of
On Fri, May 09, 2025 at 06:18:40PM +0300, Daniil Kochergin wrote:
> PR fortran/120191
>
> * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc):
>
> Call strip_kind_from_actual unconditionally.
>
>
> * gfortran.dg/pr120191.f90: New test.
This unfortunately only fixes some of the cases in the new
ned(kind=1). I've made sure TYPE_CANONICAL of the unsigned(kind=1)
type is still character(kind=1), so they are considered compatible by
the middle-end also e.g. for aliasing etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and later on for 15.2?
2025-05-09
On Fri, May 09, 2025 at 09:17:23AM +0200, Richard Biener wrote:
> RTL DSE forms store groups from unique invariant bases but that is
> confused when presented with constant addresses where it assigns
> one store group per unique address. That causes it to not consider
> 0x101:QI to alias 0x100:SI.
On Fri, May 09, 2025 at 11:01:58AM +0200, Richard Biener wrote:
> On Fri, 9 May 2025, Jakub Jelinek wrote:
>
> > On Fri, May 09, 2025 at 09:34:14AM +0200, Richard Biener wrote:
> > > > Perhaps better CONST_SCALAR_INT_P instead of CONST_INT_P?
> > >
> >
On Fri, May 09, 2025 at 09:34:14AM +0200, Richard Biener wrote:
> > Perhaps better CONST_SCALAR_INT_P instead of CONST_INT_P?
>
> Do we ever get a wide_int for Pmode/ptr_mode? But sure, I can
Most likely not. Only if we start supporting > 64-bit pointers.
Jakub
On Thu, May 08, 2025 at 02:50:27PM +0100, Jonathan Wakely wrote:
> Document that std::to_chars and std::from_chars are complete, mentioning
> the libraries used for floating-point types.
>
> libstdc++-v3/ChangeLog:
>
> * doc/xml/manual/status_cxx2017.xml: Update status for
> std::to_c
On Thu, May 08, 2025 at 03:07:29PM +0200, Christophe Lyon wrote:
> Ping?
>
> Le jeu. 17 avr. 2025, 11:21, Christophe Lyon a
> écrit :
>
> > Since this test is a 'dg-do run', it requires tls_runtime rather than
> > just tls.
> >
> > This makes the test UNSUPPORTED on targets such as arm-non-eabi,
On Thu, May 08, 2025 at 03:07:50PM +0200, Christophe Lyon wrote:
> Ping?
>
> Le jeu. 17 avr. 2025, 11:21, Christophe Lyon a
> écrit :
>
> > This test is 'dg-do compile', so require tls instead of tls_runtime.
> >
> > This enables it on targets such as arm-none-eabi configured with
> > --enable-t
nk as obvious.
Sorry for not including it with the individual commits.
2025-05-08 Jakub Jelinek
PR libfortran/120152
PR libfortran/120153
PR libfortran/120158
* gfortran.dg/pr120152_1.f90: New test.
* gfortran.dg/pr120152_2.f90: New test.
* gfortr
in expands to 0 for atype_name
GFC_UINTEGER*.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
*
symbol version as they've never been there, so the patch
adds them to a new GFORTRAN_15.2 symbol version instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120153
* Makefile.am (i_maxloc1_c): Add gen
/regtested on x86_64-linux and i686-linux, ok for trunk
and 15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120152
* Makefile.am (i_maxloc1_c): Readd generated/maxloc1_4_i8.c,
generated/maxloc1_8_i8.c, generated/maxloc1_16_i8.c,
generated/maxloc1_4_i16.c, generated
On Tue, May 06, 2025 at 05:11:51PM -0400, Jason Merrill wrote:
> Well, that's all very complicated but seems to make sense. Can you also add
> short rationale comments to the changes in linemap_add and plugin_init?
So like this?
2025-05-07 Jakub Jelinek
PR preproce
On Tue, May 06, 2025 at 01:28:16PM +0200, Jørgen Kvalsvik wrote:
> Mostly because it would make the print more noisy, and because by the time
> we have 4 billion prime paths, all systems would probably already have been
> crushed under the load of computing them.
>
> I'm happy to change to fmt_siz
On Tue, May 06, 2025 at 01:17:54PM +0200, Richard Biener wrote:
> On Tue, 6 May 2025, Jørgen Kvalsvik wrote:
>
> > Some systems don't support the %zu format modifier for size_t, such as
> > hppa64-hp-hpux. We don't really need the full width of size_t for
> > printing the number of prime paths as
lias optimization, such that we can create
aliases even when maybe_clone_body is called not at at_eof time, without trying
to repeat it in maybe_optimize_cdtor.
2024-05-15 Jakub Jelinek
Jason Merrill
PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Remove.
w_plugin.so scan-file
static_assert[^\n\r]*6[^\n\r]*== 6
and with vanilla 14 branch I get
FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c
-fplugin=./location_overflow_plugin.so scan-file
static_assert[^\n\r]*5[^\n\r]*== 5
and with the patch on 14 branch I get all PASSes.
2025-05-
RCE_LINE (from, linemap_included_from (map - 1)) + 1;
way only if from[1] is a LC_RENAME map (rather than the usual
LC_ENTER one), that should limit it to the problematic cases of when
parse_include peeked after EOL and had to create LC_RENAME map with
the same start_location as the LC_ENTER after it.
On Mon, May 05, 2025 at 09:02:15AM +0200, Jakub Jelinek wrote:
> The other option would be
> + if (ll_bitsize != lr_bitsize)
> + return 0;
> if (!lr_and_mask.get_precision ())
> lr_and_mask = sign;
> else
> lr_and_mask &=
Hi!
I've noticed a typo on the flag name, fixed thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed
to trunk as obvious.
2025-05-05 Jakub Jelinek
* config/i386/i386.md (truncsfbf2): Fix comment typo,
unsafte -> unsafe.
--- gcc/config/i386/i3
sure what is right. So the second option
might be safest.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
or shall I go with the second option?
2025-05-05 Jakub Jelinek
PR tree-optimization/120074
* gimple-fold.cc (fold_truth_andor_for_ifcombine): Use wid
On Sat, May 03, 2025 at 01:32:35PM +0200, Richard Biener wrote:
> Any reason for unsigned long long vs. uint64_t for the following?
>
> -size_t attr;// See cbl_field_attr_t
> +unsigned long long attr;// See cbl_field_attr_t
Because it needs to be handled the same by th
On Fri, May 02, 2025 at 12:01:14PM -0500, Robert Dubner wrote:
> All we can do is see what happens. So, please, apply your patches to
> trunk. If you can do that soonish (and since it's not easy to figure out
Committed now.
Note, there is one last thing for the i686 -> x86_64 cross-compiler,
wh
hout
it the FE is hashing padding bits which contain random garbage and making
code generation decisions based on that. That is very much against the
reproduceability requirements.
Bootstrapped/regtested on x86_64-linux and tested with i686-linux ->
x86_64-linux cross, ok for trunk?
2025-05-02
On Sun, Apr 06, 2025 at 03:39:27PM +0200, Jakub Jelinek wrote:
> Right now it is not possible to even build cross-compilers from 32-bit
> architectures to e.g. x86_64-linux or aarch64-linux, even from little-endian
> ones.
>
> The following patch attempts to fix that.
>
&g
> - gimple_infer_range infer(s);
> + gimple_infer_range infer(s, this);
>if (infer.num () == 0)
> return;
>
> --
> 2.45.0
>
Now that this patch is in, I've retested my patch and it works fine.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok f
RAW_DATA_CST in the initializers.
For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is
always valid, for !TYPE_UNSIGNED we need to check for 128-255 values
being turned into negative ones.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
2025-05-0
On Fri, May 02, 2025 at 12:30:52PM +0200, Florian Weimer wrote:
> The termio structure will be removed from glibc 2.42. It has
> been deprecated since the late 80s/early 90s.
>
> Cherry-picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763
> ("[sanitizer_common] Remove interceptors for
On Fri, May 02, 2025 at 10:53:03AM +0200, Florian Weimer wrote:
> gcc/c/
>
> PR c/120055
> * c-typeck.cc (convert_arguments): Check if fundecl is null
> before checking for builtin function declaration.
>
> gcc/testsuite/
>
> * gcc.dg/Wdeprecated-non-prototype-6.c: New te
On Thu, May 01, 2025 at 10:02:06PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Thu, May 01, 2025 at 04:30:56PM +, Joseph Myers wrote:
> >> On Thu, 1 May 2025, Christopher Bazley wrote:
> >>
> >> > Changes in v2:
> >> >
On Thu, May 01, 2025 at 08:38:57PM +0100, Richard Sandiford wrote:
> Tejas Belagod writes:
> > Fix udr-sve.c target test that to check for the correct results based on the
> > OpenMP clauses used. The test was first written with a misunderstood
> > functionality of the reduction clause.
> >
> > T
On Thu, May 01, 2025 at 04:30:56PM +, Joseph Myers wrote:
> On Thu, 1 May 2025, Christopher Bazley wrote:
>
> > Changes in v2:
> > - Fixed a formatting issue.
> > - Added a test.
>
> Thanks. I have no further comments; I hope someone more familiar with
> debug info handling can review thi
_TAG_GNU_structured_binding_pack as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-05-01 Jakub Jelinek
PR c++/117783
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_structured_bindings
predefined value for C++26 from 202403L
for trunk?
2025-04-30 Jakub Jelinek
PR c++/117827
* init.cc (build_vec_init): Push to *cleanup_flags clearing of rval
instead of setting of iterator to maxindex.
--- gcc/cp/init.cc.jj 2025-01-24 19:26:31.980193087 +0100
+++ gcc/cp/init.cc 2025-01-24 19:45:0
On Mon, Apr 21, 2025 at 04:39:55PM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- 8< --
>
> While working on PR119162 it occurred to me that it would be simpler to
> detect the problem of a value referring to a heap allocation if we stopped
> setting TREE_STATIC on
On Mon, Apr 28, 2025 at 07:27:31PM +0200, Josef Melcr wrote:
> As for the attribute, I am honestly not too sure about what to do, as clang
> is
> not consistent in with its own indexing, be it with the unknown values, or
> with
> 'this'. I've tried to remain consistent with GCC's indexing style. I
On Tue, Apr 29, 2025 at 08:42:42AM +0200, Richard Biener wrote:
> > I think the new version is far more honest. It's been bothering me for a
> > bit but couldn't figure out the right phrasing to edit. Thanks.
>
> Jakub, are the var-tracking -O0 vs. -On bits accurate?
Yes. LGTM.
Jakub
On Mon, Apr 28, 2025 at 01:03:11PM -0700, Andrew Pinski wrote:
> > Otherwise LGTM.
>
> Just to double check, was this an approval after the fix for the call
> to useless_type_conversion_p?
Yes.
Jakub
On Sun, Apr 27, 2025 at 11:56:21AM +0200, Josef Melcr wrote:
> * builtin-attrs.def (0): New int list.
This is just weird. Write
* builtin-attrs.def: Add DEF_LIST_INT_INT (0,2).
?
> +DEF_CALLBACK_ATTRIBUTE(GOMP, 1, 0)
> +DEF_CALLBACK_ATTRIBUTE(GOMP, 1, 2)
> +DEF_CALLBACK_ATTRIBUTE(O
On Fri, Apr 25, 2025 at 09:12:45PM -0700, Andrew Pinski wrote:
> --- a/gcc/tree-tailcall.cc
> +++ b/gcc/tree-tailcall.cc
> @@ -1083,57 +1083,74 @@ find_tail_calls (basic_block bb, struct tailcall
> **ret, bool only_musttail,
> {
>bool ok = false;
>value_range val;
> - tre
On Fri, Mar 28, 2025 at 12:20:18PM +0100, Jakub Jelinek wrote:
> Here is the incremental patch I was talking about.
> For noop sets, we don't need to test much, they can go to i2
> unless that would violate i3 JUMP condition.
>
> With this the try_combine on the pr119291.c t
On Sat, Apr 19, 2025 at 08:33:48PM -0700, Andrew Pinski wrote:
> > + {
> > + tree other_value = NULL_TREE;
> > + /* If we have a function call that we know the return value is
> > the same
> > +as the argument, try the argument too. */
> > + int flags = gi
On Fri, Apr 25, 2025 at 01:55:58PM +0100, Andre Vieira (lists) wrote:
> Differences from v1:
>
> Made suggested changes to testcase and moved to target-agnostic area.
>
> gcc/ChangeLog:
>
> PR rtl-optimization/116479
> * modulo-sched.cc (doloop_register_get): Reject conditions with
>
hat case)?
2025-04-25 Jakub Jelinek
PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register in the PARALLEL case either.
Hi!
I've committed the following patch to rotate news, chose to move
202{2,3}-ish items to news.html. We'll soon have 14.3/13.4 releases
so the first column will be about the same length as the second.
diff --git a/htdocs/index.html b/htdocs/index.html
index 8bdc4071..a662ab09 100644
--- a/htdoc
is
[129]GCC 15.1
or something like that with an URL later on
129. https://gcc.gnu.org/gcc-15/changes.html#15.1
The following patch handles this.
Tested during gcc 15.1 release process, committed to trunk.
2025-04-25 Jakub Jelinek
* gcc_release: Allow optional \[[0-9]+\] before GCC
On Thu, Apr 24, 2025 at 12:39:59PM +, Kyrylo Tkachov wrote:
> > The third case looks undesirable, -fno-ipa-reorder-for-locality is the
> > default and shouldn't affect anything, whether explicit or implicit.
>
> I see. With this patch I don’t get a complaint on
> -flto-partition=balanced -fno
On Thu, Apr 24, 2025 at 12:05:06PM +, Kyrylo Tkachov wrote:
> >>> On 24 Apr 2025, at 12:09, Jakub Jelinek wrote:
> >>>
> >>> On Thu, Apr 24, 2025 at 09:54:09AM +, Kyrylo Tkachov wrote:
> >>>>> I'd have expected instead
ory.
Ok, so like this then if it passes bootstrap/regtest?
So far tested with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m64,-m31\}
s390.exp=pr119873*'
in a cross-compiler.
2025-04-24 Jakub Jelinek
Stefan Schulze Frielinghaus
PR target/119873
On Thu, Apr 24, 2025 at 09:54:09AM +, Kyrylo Tkachov wrote:
> > I'd have expected instead of the LTO_PARTITION_DEFAULT checks one should be
> > testing !opts_set->x_flag_lto_partition (i.e. -flto-partition=balanced
> > should be the default, but when not specified explicitly, it would really
>
On Thu, Apr 24, 2025 at 10:15:08AM +, Kyrylo Tkachov wrote:
>
>
> > On 24 Apr 2025, at 12:09, Jakub Jelinek wrote:
> >
> > On Thu, Apr 24, 2025 at 09:54:09AM +, Kyrylo Tkachov wrote:
> >>> I'd have expected instead of the LTO_PARTITION_DEFAULT
On Thu, Apr 24, 2025 at 11:27:36AM +0200, Jakub Jelinek wrote:
> > This is a thinko in the logic for handling the default -flto-partition=
> > arguments. We should override it to balanced only if it stayed as default
> > up to that point. We should also be testing opts instea
On Thu, Apr 24, 2025 at 09:10:37AM +, Kyrylo Tkachov wrote:
> [resending to the list, I think there might have been an error with the
> previous message]
>
> Hi all,
>
> This is a thinko in the logic for handling the default -flto-partition=
> arguments. We should override it to balanced onl
On Tue, Apr 01, 2025 at 11:51:49AM +0200, Jakub Jelinek wrote:
> Here it is, ok if it passes bootstrap/regtest? I'll queue the interdiff
> between this patch and the previous one for GCC 16.
Here is the interdiff to improve the tail recursion handling also for
non-musttail calls.
B
xplicit -Wunused-but-set-{variable,parameter}={1,2} to select
a different level.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Though, I'm afraid the gofrontend part will need to go in separately through
upstream.
2025-04-24 Jakub Jelinek
PR c/44677
gcc/
On Wed, Apr 23, 2025 at 04:46:04PM +0100, Andre Vieira (lists) wrote:
> On 23/04/2025 16:22, Jakub Jelinek wrote:
> > On Wed, Apr 23, 2025 at 03:57:58PM +0100, Andre Vieira (lists) wrote:
> > > +++ b/gcc/testsuite/gcc.target/aarch64/pr116479.c
> > > @@ -0,0 +
On Wed, Apr 23, 2025 at 03:57:58PM +0100, Andre Vieira (lists) wrote:
> +++ b/gcc/testsuite/gcc.target/aarch64/pr116479.c
> @@ -0,0 +1,20 @@
> +/* PR 116479 */
> +/* { dg-do run } */
> +/* { dg-additional-options "-O -funroll-loops -finline-stringops
> -fmodulo-sched --param=max-iterations-computa
1 - 100 of 2325 matches
Mail list logo
