those.
Bootstrapped on x86_64-linux and i686-linux, regtest ongoing, ok for trunk
if it passes?
2025-01-17 Jakub Jelinek
gcc/c/
* c-decl.cc (names_builtin_p): Return 1 for RID_C23_VA_START and
RID_VA_ARG.
gcc/cp/
* cp-objcp-common.cc (names_builtin_p): Return 1 for RID_VA
so that the
binary search will just care about that last element.
Bootstrapped on x86_64-linux and i686-linux, regtests pending, ok
for trunk if it passes?
2025-01-17 Jakub Jelinek
PR c++/118534
* constexpr.cc (find_array_ctor_elt): Don't return i early if
i == end
we didn't
know how to dump RAW_DATA_CST, so I've added support for that too.
Bootstrapped on x86_64-linux and i686-linux, regtests pending, ok
for trunk if it passes?
2025-01-17 Jakub Jelinek
PR c++/118532
* call.cc (add_list_candidates): Handle RAW_DATA_CST among in
_ELTS and nowhere else.
Thus, the following patch expands the RAW_DATA_CSTs from initializers
into multiple INTEGER_CSTs in the returned vector.
Bootstrapped on x86_64-linux and i686-linux, regtests pending, ok
for trunk if it passes?
2025-01-17 Jakub Jelinek
PR c++/118528
trunk as obvious.
2025-01-17 Jakub Jelinek
* c-c++-common/cpp/embed-10.c: Allow a different error wording for
C++.
--- gcc/testsuite/c-c++-common/cpp/embed-10.c.jj2024-09-12
11:05:22.0 +0200
+++ gcc/testsuite/c-c++-common/cpp/embed-10.c 2025-01-17 10:00
Hi!
I'd like to revert the r15-6448-gd09628742bb17719360ff447a8e604f5c6801bdf
reversion (of course without doing git revert of that because that breaks
ChangeLog generation) soon.
In order to do that and feel comfortable about that, I've performed
an x86_64-linux and i686-linux bootstrap/regtest
On Fri, Jan 17, 2025 at 12:37:49PM +, Sam James wrote:
> So far, testing has gone well on my end (multilib issues fixed too), but
> I suspect it introduced an issue with RPATH:
libtool install into gcc/$(MULTISUBDIR) isn't a good idea.
Jakub
rt, &end);
gcc_assert (ok);
if (code == 's' || code == 't')
ival = start;
else
ival = end;
}
break;
which likely should be also output_operand_lossage but I haven't
produces also valid GENERIC. Without it we got
(int) p == b where b had _BitInt(32) type, so incompatible types.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-17 Jakub Jelinek
PR tree-optimization/118522
* match.pd ((FTYPE) N CMP (FTYPE) M): Add
visibility with
VISIBILITY_ANON for !TREE_PUBLIC (but are all !TREE_PUBLIC constrained
visibility) or do it only in the cp_finish_decomp case
after the copy_linkage call there.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-17 Jakub Jelinek
PR c++/118513
On Wed, Jan 15, 2025 at 04:48:59PM -0500, Jason Merrill wrote:
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -11686,6 +11686,7 @@ fold_sizeof_expr (tree t)
> > false, false);
> > if (r == error_mark_node)
> > r = size_one_node;
> > + r = cp_fold
e toplevel
extended asm documentation (it was in the Basic Asm remarks and Extended Asm
section's remark still said it is not valid).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15 Jakub Jelinek
* doc/extend.texi (Using Assembly Language with C): Add
vector is better and
matches what reshape_init_r does at the start of the function.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15 Jakub Jelinek
PR c++/118214
* decl.cc (struct reshape_iter): Add raw_idx member.
(cp_maybe_split_raw_dat
();
gcc_checking_assert (l >= size);
if (!std::is_trivially_destructible ::value)
vec_destruct (address () + size, l - size);
m_vecpfx.m_num = size;
Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested on the
testcase from the PR under valgrind, ok for trunk?
2025-01-15 Jakub Jeli
Hi!
This is something we should have done when -std=c++23 was made the
primary option and -std=c++2b turned into undocumented alias.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15 Jakub Jelinek
gcc/cp/
* parser.cc (cp_parser_lambda_declarator_opt
On Wed, Jan 15, 2025 at 04:33:26PM +0100, Jakub Jelinek wrote:
> I vaguely remember from writing the original patch (which introduced
> cp_maybe_split_raw_data) that here it actually mattered whether
> in the error case we move the reshape_iter or not and that it broke
> some tes
On Wed, Jan 15, 2025 at 10:27:56AM -0500, Jason Merrill wrote:
> > @@ -7432,12 +7426,18 @@ reshape_init_r (tree type, reshape_iter
> > {
> > vec *v = 0;
> > CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
> > - tree raw_init = cp_maybe_split_raw_data (d);
> > + bool inc_cur;
>
On Wed, Jan 15, 2025 at 03:17:22PM +0100, Richard Biener wrote:
> On Wed, 15 Jan 2025, Jakub Jelinek wrote:
>
> > On Wed, Jan 15, 2025 at 11:46:28AM +0100, Jakub Jelinek wrote:
> > > BTW, I think we don't optimize returns-arg stuff like that at least right
> > >
On Wed, Jan 15, 2025 at 03:16:04PM +0100, Richard Biener wrote:
> > + /* If IPA-VRP proves called function always returns a singleton
> > range,
> > +the return value is replaced by the only value in that range.
> > +For tail call purposes, pretend such replacement didn't happen. */
Hi!
The following patch attempts to document in similar style to last years
new C++23/26 papers and DRs implemented in GCC 15 (for
the papers I've used https://gcc.gnu.org/projects/cxx-status.html
as source, for DRs skimmed gcc-cvs commits with /DRs/ and left out those
that just committed a testca
On Wed, Jan 15, 2025 at 11:46:28AM +0100, Jakub Jelinek wrote:
> BTW, I think we don't optimize returns-arg stuff like that at least right
> now, and if we did, it wouldn't be through IPA-VRP, most of the returns-arg
> functions actually return a pointer, not integer and for pra
Hi!
And here is incremental (for now tested just on the new testcases)
patch to avoid VRP etc. to replace lhs of musttail call with something else.
2025-01-15 Jakub Jelinek
PR tree-optimization/118430
* tree-ssa-propagate.cc (may_propagate_copy): Return false if dest
estcase to really verify the non-tailcallable
cases weren't tail called) plus added testcase to verify the non-musttail
cases (both when written as return fncall (args); and as fncall (args);
return singletoncst;), plus follow up patch I'll post next?
2025-01-15 Jakub Jelinek
On Wed, Jan 15, 2025 at 10:05:35AM +0100, Richard Biener wrote:
> > When we have return somefn (whatever); where somefn is normally tail
> > callable and IPA-VRP determines somefn returns a singleton range, VRP
> > just changes the IL to
> > somefn (whatever);
> > return 42;
> > (or whatever th
expansion decides it can't use the tail
call, we'll still expand the return 42; or similar statement, and if it
decides it can use the tail call, that part will be ignored and we'll emit
normal tail call.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15
apped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2025-01-15 Jakub Jelinek
PR ipa/116068
* cgraphunit.cc (symbol_table::process_new_functions): Call
bitmap_obstack_initialize (NULL); and bitmap_obstack_release (NULL)
around processing the func
complain);
> > val = build_static_cast (input_location, rettype, seql,
> >complain);
>
> Apparently this also needs to happen when !defining.
Ok, so like this then?
2025-01-14 Jakub Jelinek
PR c++/118387
* metho
On Mon, Jan 13, 2025 at 06:38:00PM +, Richard Sandiford wrote:
> In g:06c4cf398947b53b4bfc65752f9f879bb2d07924 I mishandled signed
> comparisons of comparison results on STORE_FLAG_VALUE < 0 targets
> (despite specifically referencing STORE_FLAG_VALUE in the commit
> message). There, (lt TRUE
On Mon, Jan 13, 2025 at 07:29:52PM +0100, Iain Buclaw wrote:
> For example, changing the common package sources we end up with the
> following, though can't say I'm a strong fan of having test and
> optionally mkdir ran on every recipe execution.
You also then need to handle it for cleaning etc.
has no elements and the static cast from
> > https://eel.is/c++draft/class.compare#class.spaceship-3.sentence-2
> > ?
>
> That seems pretty obviously what we want, and is what the other compilers
> implement.
So like this?
Will you handle the defect report (unless you think not
On Mon, Jan 13, 2025 at 02:45:28PM +0100, Arsen Arsenović wrote:
> > So the former d/.deps/file.Po which handled both d/dmd/common/file.d and
> > d/dmd/root/file.d in your case would be d/.deps/d-common-file.o.d and
> > d/.deps/d-root-file.o.d while with the above DEPFILE it would be
> > d/.deps/co
ge in between just looks weird and IMHO should be ;; prefixed.
The following patch does that, ok for trunk?
2025-01-13 Jakub Jelinek
PR target/115910
* expr.cc (expand_expr_divmod): Prefix the TDF_DETAILS note with
";; " and add a space before (nee
On Mon, Jan 13, 2025 at 11:00:09AM +0100, Jakub Jelinek wrote:
> Why do you need there the directory or suffix?
> $(*F) is clearly bad, because there are rules like
> d/%.o: d/dmd/%.d
> $(DCOMPILE) $(D_INCLUDES) $<
> $(DPOSTCOMPILE)
>
> d/comm
enames:
for i in gcc/d/*.cc; do j=`basename $i .cc`; find gcc/d -name $j.d; done
So just (or if you want a helper variable, perhaps it should standa for the
whole $(@D)/$(DEPDIR)/$(basename $(@F)) part?
2025-01-13 Arsen Arsenović
Jakub Jelinek
* Make-lang.in (D
AIL: hash
ok for trunk?
2025-01-12 Jakub Jelinek
PR tree-optimization/117997
PR middle-end/118415
* expr.cc (assemble_crc_table): Make static, remove id argument,
use output_constant_def. Emit note if -fdump-rtl-expand-details
about which table has been e
On Sat, Jan 11, 2025 at 01:52:59AM -0800, Andrew Pinski wrote:
> The problem is for inline-asm goto, the outer rtl insn type
> is a jump_insn and get_attr_length does not handle ASM specially
> unlike if the outer rtl insn type was just insn.
>
> This fixes the issue by adding support for both CAL
On Sat, Jan 11, 2025 at 08:25:32PM +0100, Jakub Jelinek wrote:
> That is not true.
Implementation-wise, in C17 say
void foo ();
void bar (void);
TYPE_ARG_TYPES (TREE_TYPE (foo_decl)) == NULL
TYPE_ARG_TYPES (TREE_TYPE (bar_decl)) == void_list_node
but in C23 both have TYPE_ARG_TYPES void_list_n
On Sat, Jan 11, 2025 at 01:55:42PM -0500, David Malcolm wrote:
> + if ((takes_void_p (fntype_a) && takes_int_p (fntype_b))
> + || (takes_int_p (fntype_a) && takes_void_p (fntype_b)))
> +{
> + inform (UNKNOWN_LOCATION,
> + "the meaning of %<()%> in function declarations chan
On Thu, Jan 09, 2025 at 09:39:49PM -0500, Jason Merrill wrote:
> > @@ -6685,7 +6692,14 @@ gimplify_modify_expr (tree *expr_p, gimp
> > /* Don't do this for calls that return addressable types,
> > expand_call
> > relies on those having a lhs. */
> > && !(TREE_ADDRESSABLE (TRE
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672496.html
(waiting for review)
uses the new function introduced in the second patch to fix up
unify deduction of array sizes.
Ok for trunk?
2025-01-10 Jakub Jelinek
PR c++/118390
* cp-tree.h (count_ctor_elements): Declare
on't
add error_mark_node statement silently, but as the function isn't deleted,
we just silently emit it.
Should the standard be amended to say that the operator should be deleted
even if it has no elements and the static cast from
https://eel.is/c++draft/class.compare#class.spaceship-3.
.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-10 Jakub Jelinek
PR c/118376
* c-parser.cc (c_parser_postfix_expression): Call
set_c_expr_source_range before break in the __builtin_stdc_rotate_*
case.
* gcc.dg/pr118376.c: New
y take that out,
and if you think being there extra careful about TREE_TYPE (val) isn't
needed either because it must be always integer_type_node and that libcpp
shouldn't create CPP_EMBED for avr -mint8 with 128+ values, that conditional
could be just if (!TYPE_UNSIGNED (elt_type))
will push this one promptly.
This was committed without a testcase, which IMHO shouldn't hurt.
Ok for trunk?
2025-01-09 Jakub Jelinek
PR target/118362
* gcc.c-torture/compile/pr118362.c: New test.
* gcc.target/s390/pr118362.c: New test.
--- gcc/testsuite/gcc.c-to
On Thu, Jan 09, 2025 at 06:12:51PM +0100, Andre Vehreschild wrote:
> Yes, that is what I had in mind. Being German I don't see any problem with the
> explanation, but that is better judged by a native English speaker.
>
> Is the send patch hunk intentional where only indentation is changed? I
> h
On Thu, Jan 09, 2025 at 03:28:28PM +0100, Jakub Jelinek wrote:
> So like this?
Thomas mentioned bad wording in a private mail. Here is a better patch:
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
27;ve also added an assert, I think it isn't really needed to assert that
symbol[i].id == a in each case, just that we increment i for all the cases.
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
On Thu, Jan 09, 2025 at 01:17:24PM +0100, Tobias Burnus wrote:
> A case where 'omp error' diagnostic should be delayed - and (here) suppressed:
>
> program_control/sources/error.1.c:15:23: error: ‘pragma omp error’
> encountered: GNU compiler required.
>15 | otherwise(error at(com
On Wed, Jan 08, 2025 at 01:33:15PM -0500, Marek Polacek wrote:
> On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote:
> > Hi!
> >
> > The following testcase ICEs due to re-entering diagnostics.
> > When diagnosing -Wformat-security warning, we try to prin
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/118337
> * module.cc (use_iso_fortran_env_module): Prevent additional run
> over (un-)signed ints and assign kind directly.
> ---
> gcc/fortran/module.cc | 13 ++---
On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote:
> I'm testing for that instead:
> --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100
> +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100
> @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (voi
On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> One of the issues are lines:
>
> module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
> adjacent maybe?!
>
> I have changed this:
>
> diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
> index
On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> Hi,
>
> I have added this small patch (attached). Unfortunately I got regressions
>
> some in iso_fortran_env_8.f90
> and several in unsigned_NN.f90 tests.
>
> Just retesting w/o my patch and already seeing the iso_fortran_env
On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote:
> I think your patch is enough, we don't need to target same-bytes formats
> between module versions.
I can confirm the ICE on the small reproducer I've posted is gone with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729
cpp_constexpr_dynamic_alloc >= 201907L
asm ((T{}));
#endif
}
part which I think should work (it works with static_assert) but doesn't
really work with asm. Will look at it incrementally, just need to work on
some mass rebuild ICEs and backporting now.
So far just light
On Wed, Jan 08, 2025 at 02:35:56PM +0100, Mark Wielaard wrote:
> > --- gcc/dwarf2out.cc.jj 2025-01-02 11:23:35.541251268 +0100
> > +++ gcc/dwarf2out.cc2025-01-07 10:09:16.866866563 +0100
> > @@ -8755,6 +8755,14 @@ break_out_comdat_types (dw_die_ref die)
> > unit = new_die (DW_T
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
> Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
> >
> > The full list of changes with the posted patches is
> > (first a.mod, then b.mod, 14 -> 15) below.
> > I have no idea what adds those __copy_* elts
On Wed, Jan 08, 2025 at 12:42:39PM +0100, Andre Vehreschild wrote:
> Er, call me stupid, but what is the easiest way to apply your patch? 'git am'
> on
> the part from the date-line to the end stripping your greetings, always leads
> to unrecognized patch format. Using `patch -p1` did not work eit
On Wed, Jan 08, 2025 at 11:57:32AM +0100, Giuseppe D'Angelo wrote:
> On 08/01/2025 11:49, Jakub Jelinek wrote:
> > > +#ifndef _GLIBCXX26_CONSTEXPR
> > > +# if __cplusplus >= 202303L
> > Shouldn't that be 202400L instead? I mean that is what
> > -
e start of the
> last forwprop? I think in the end we may want to have a special
> pre-expand (at ISEL time?) folding and have extra patterns enabled
> there (and some disabled eventually), but I think we don't want to
> introduce this now.
>
> With the rest I agree.
So l
On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> type
> getting the recursive marker enforces the generation of the vtype for it. I
> don't see yet, why the iso_c_binding_C_funptr should be marked as r
On Wed, Jan 08, 2025 at 11:44:50AM +0100, Giuseppe D'Angelo wrote:
> The attached patch adds _GLIBCXX26_CONSTEXPR, in preparation for adding
> `constexpr` on some functions starting in C++26.
>
> Thanks,
> --
> Giuseppe D'Angelo
> From 61115549376a29558eb7753f525daf671c6da929 Mon Sep 17 00:00:00
On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote:
> marking the vtypes as recursive is odd, but should not be taken as any
> incompatibility marker. Pre version 15 gfortran does not check the recursive
> attr on types. So whether it is set or not, is of no concern to gfortran <=
>
On Wed, Jan 08, 2025 at 10:47:39AM +0100, Richard Biener wrote:
> I wonder if we can somehow add some test coverage? Are .mod files
> target independent and thus can we include them in the testsuite?
They are, but they are compressed and having binary data in the testsuite
is a problem. But perh
59 -> 63, numeric_storage_size 60 -> 64, etc.
So, I really don't know if it is feasible to ensure backwards compatibility.
Plus how we would actually test whether we are able to accept the older
modules in newer compilers.
2025-01-08 Jakub Jelinek
PR fortran/118337
also MOD_VERSION "15",
but it is unfinished.
2025-01-08 Jakub Jelinek
PR fortran/118337
* module.cc (MOD_VERSION): Bump to "16".
--- gcc/fortran/module.cc.jj2025-01-02 11:47:31.697201637 +0100
+++ gcc/fortran/module.cc 2025-01-07 21:41:46.866494776 +010
, there is forwprop before vrp, so the patch
introduces a new PROP for vrp2 finish, after which there is another
forwprop. Or do you have ideas about what other condition could be used
for late matching only?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-08 Jak
On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > So, this patch is an alternative to the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > patch, which had the major problem that it required changing all the
> > DWARF consumers to be able to debug C17 or
unique, one can't redeclare them and
without it we really ICE because their base vars have no name.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-07 Jakub Jelinek
* module.cc (trees_out::core_vals): Note DECL_VALUE_EXPR even for
vars outsi
er transformed into INDENTIFIER_NODEs. Or shall we sorry if it is
used in templates for now? Or say temporarily turn into some internal
attribute?
2025-01-07 Jakub Jelinek
PR c++/118277
* cp-tree.h (finish_asm_string_expression): Declare.
* semantics.cc (finish_asm_stri
ested on x86_64-linux and i686-linux, ok for trunk?
2025-01-07 Jakub Jelinek
include/
* dwarf2.h (enum dwarf_source_language): Fix comment pasto.
(enum dwarf_source_language_name): New type.
* dwarf2.def (DW_AT_language_name, DW_AT_language_version): New
DWA
On Tue, Jan 07, 2025 at 11:20:11PM +0800, Gerald Pfeifer wrote:
> On Tue, 7 Jan 2025, Simon Martin wrote:
> > Noticed while trying to understand when I can expect the GCC 15 branch
> > to be created: the GCC 15 release criteria page still mentions GCC 14.
> >
> > I'll push this as obvious.
>
> Th
On Tue, Jan 07, 2025 at 03:49:26PM +0100, Richard Biener wrote:
> When nonlocal goto lowering creates an artificial label it fails
> to adjust its context.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress
> (I doubt good test coverage is present for non-local gotos)
>
> OK when t
On Tue, Jan 07, 2025 at 02:07:58PM +0100, Jakub Jelinek wrote:
> Stage1:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/6623
Hi!
I'd like to ping 10 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672040.html
P1 - Fix ICEs with large initializer lists or ones including #embed [PR118124]
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672041.html
P1 - Fix up maybe_init_list_as_array for
On Wed, Dec 18, 2024 at 12:15:15PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2024 at 05:07:40PM +0100, Jakub Jelinek wrote:
> > I'd like to ping the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
> > patch.
> >
> > The patches it
On Mon, Jan 06, 2025 at 11:01:18AM -0500, Siddhesh Poyarekar wrote:
> Ping!
>
> On 2024-12-19 08:16, Siddhesh Poyarekar wrote:
> > Denormal behaviour is well defined for IEEE128 long doubles, so don't
> > XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> > long double ABI.
>
On Mon, Jan 06, 2025 at 11:59:08AM +0100, Stefan Schulze Frielinghaus wrote:
> For some targets uptr is mapped to unsigned int and size_t to unsigned
> long and sizeof(int)==sizeof(long) holds. Still, these are distinct
> types and type checking may fail. Therefore, replace uptr by
> usize/SIZE_T
On Mon, Jan 06, 2025 at 09:55:18AM +0100, Stefan Schulze Frielinghaus wrote:
> From: Vitaly Buka
>
> Fix type in a few related Min() calls.
>
> Follow up to #116957.
>
> Co-authored-by: Stefan Schulze Frielinghaus
>
> Cherry picked from LLVM commit 6dec33834d1fd89f16e271dde9607c1de9554144
> (
On Mon, Jan 06, 2025 at 09:55:16AM +0100, Stefan Schulze Frielinghaus wrote:
> For some targets uptr is mapped to unsigned int and size_t to unsigned
> long and sizeof(int)==sizeof(long) holds. Still, these are distinct
> types and type checking may fail. Therefore, replace uptr by
> usize/SIZE_T
On Mon, Jan 06, 2025 at 09:55:17AM +0100, Stefan Schulze Frielinghaus wrote:
> Cherry picked from LLVM commit ce44640fe29550461120d22b0358e6cac4aed822.
>
> PR sanitizer/117725
This line needs to be tab indented, best put right before the * interception/
line.
> libsanitizer/ChangeLog:
>
>
On Mon, Jan 06, 2025 at 09:55:19AM +0100, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to 6dec33834d1fd89f16e271dde9607c1de9554144 and
> #116957 and #119114.
>
> Cherry picked from LLVM commit 65a2eb0b1589590ae78cc1e5f05cd004b3b3bec5.
>
> PR sanitizer/117725
> libsanitizer/ChangeLog:
for trunk?
2025-01-03 Jakub Jelinek
PR c++/117825
* typeck.cc (cp_build_function_call_vec): Don't call
check_function_arguments if complain doesn't have tf_warning bit set.
* g++.dg/warn/pr117825.C: New test.
--- gcc/cp/typeck.cc.jj 2025-01-02 11:47
too large, it isn't worth
trying to optimize it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-03 Jakub Jelinek
PR tree-optimization/118224
* tree-ssa-dce.cc (is_removable_allocation_p): Don't return true
for allocations wit
On Fri, Jan 03, 2025 at 12:03:06PM -0600, Robert Dubner wrote:
> > As has been noted, wide_int can be used for large integer arithmetic
> > within the compiler.
>
> My needs are modest; we use __int128 in only a few places in the host
> code. If __int128 were supported by 32-bit GCC, we'd would
On Fri, Jan 03, 2025 at 12:39:08PM +0100, Jakub Jelinek wrote:
> Should be all !DECL_NAME (decl) MK_unique? Or just
> DECL_DECOMPOSITION_P (decl) && !DECL_NAME (decl)?
> Structured bindings can't be redeclared, so I guess they are unique.
With
--- gcc/cp/module.
care about ordering
of anything and ICEs without/with the other patches the same.
Should be all !DECL_NAME (decl) MK_unique? Or just
DECL_DECOMPOSITION_P (decl) && !DECL_NAME (decl)?
Structured bindings can't be redeclared, so I guess they are unique.
Jakub
2025-01-03
same as as a sequence of
INTEGER_CSTs that were used previously instead.
The only slight complication is that if ce->value is the last nonzero
element, we need to skip the zeros at the end of RAW_DATA_CST.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-03 Jakub
cope with it just fine,
I'm using build_int_cst which also doesn't care what type it is,
instead of bitsize_int, which I've used in PR117190 fix (previously
it was size_int).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-03 Jakub Jelinek
t is appropriate for the testsuite.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-03 Jakub Jelinek
* tree-ssa-forwprop.cc (check_ctz_array): Use tree_fits_shwi_p instead
of just TREE_CODE tests for INTEGER_CST.
--- gcc/tree-ssa-forwprop.cc
On Thu, Jan 02, 2025 at 11:51:20AM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > libgdiagnostics/conf.py breaks update-copyright.py --this-year,
> > which only accepts copyright year in u'' literals in python files,
> > not in ''.
> >
ifference is just the expected addition of -2025 in tons of spots,
nothing else.
Committed to trunk as obvious.
2025-01-02 Jakub Jelinek
* doc/libgdiagnostics/conf.py: Use u'' instead of '' in
project and copyright initialization.
--- gcc/doc/libgdiagn
ChangeLogs with yearly cadence and committed manual
as well as scripted copyright year updates. See
https://gcc.gnu.org/r15-6495
https://gcc.gnu.org/r15-6496
https://gcc.gnu.org/r15-6497
https://gcc.gnu.org/r15-6500
https://gcc.gnu.org/r15-6501
for details.
2025-01-02 Jakub Jelinek
* upda
ux and i686-linux, ok for trunk?
2025-01-02 Jakub Jelinek
* tree-ssa-forwprop.cc (check_ctz_array): Handle also RAW_DATA_CST
in the CONSTRUCTOR_ELTS.
* gcc.dg/pr90838-2.c: New test.
--- gcc/tree-ssa-forwprop.cc.jj 2024-12-28 00:12:11.185146287 +0100
+++ gcc/tree-ssa-
ready) and modifying the original CONSTRUCTOR_ELTS only if reuse
is true and we used the whole RAW_DATA_CST (with zero raw_idx); which means
just modifying its type in place.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-02 Jakub Jelinek
PR c++/118214
* decl.cc (
x and i686-linux, ok for trunk?
2024-12-28 Jakub Jelinek
PR tree-optimization/118207
* gimple-fold.cc (fold_array_ctor_reference): For RAW_DATA_CST,
just set val to build_int_cst and fall through to the normal
element handling code instead of returning build_int
Hi!
The test used #include "", so FAILed everywhere with
fatal error: : No such file or directory
Tested on x86_64-linux with RUNTESTFLAGS=conformance.exp=pr118196.cc
without/with the patch, committed to trunk as obvious.
2024-12-28 Jakub Jelinek
PR libstd
On Fri, Dec 20, 2024 at 05:38:57PM +0100, Christoph Müllner wrote:
> FAILs have been reported for several tree-ssa vector-*.c tests
> on i686-linux or on x86_64-linux with -m32.
> This patch addresses these fails by setting the necessary -msse2 flags.
>
> This patch also streamlines all tests to u
On Fri, Dec 20, 2024 at 05:38:56PM +0100, Christoph Müllner wrote:
> A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
> This patch adds two test cases for PR118149.
> These tests are different than other tests in that one of the
> vec-perm selectors contains indices in descending
On Fri, Dec 20, 2024 at 04:22:19PM +0100, Christoph Müllner wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr118149-2.c
> @@ -0,0 +1,37 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fdump-tree-forwprop1-details -Wno-psabi" } */
> +/* { dg-options "-msse2" { target i?86-*-* x8
1 - 100 of 1972 matches
Mail list logo
