1BZ" \
"SU5HMy4gIElmIG5vdCBzZWUKPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNlbnNlcy8+LiAgKi8KCiNp" \
"Zm5kZWYgVFJFRV9TU0FfRENFX0gKI2RlZmluZSBUUkVFX1NTQV9EQ0VfSApleHRlcm4gdm9pZCBz" \
"aW1wbGVfZGNlX2Zyb21fd29ya2xpc3QgKGJpdG1hcCwgYml0bWFwID0gbnVsbHB0cik7CiNlbmRp" \
"Zg==")
# 1 "embed-do.c"
,10
Is that wha
Hi!
On Wed, Jun 19, 2024 at 08:29:37PM +0200, Jakub Jelinek wrote:
> Right now the patch only supports a single huge string literal in there,
> not concatenation of multiple strings, dunno if we shouldn't add support
> for that so that we don't run into the line length limits f
ype around and
needing to handle it though.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-19 Jakub Jelinek
Martin Uecker
PR c/114930
PR c/115502
gcc/c/
* c-decl.cc (c_update_type_canonical): Assert t is main variant
complexexpr_stmt, or because they should be really rare, this
patch just disables the load optimization if at least one load use is
a COMPLEX_EXPR (like we do already for PHIs, calls, asm).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-19 Jakub Jelinek
PR tree-opt
ly multiple of 4); disadvantage is then that we lex that not into
a single huge string but perhaps hundreds/thousands/millions of short
CPP_STRINGs that would be gathered together.
Thoughts on that?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-19 Jakub Je
On Wed, Jun 19, 2024 at 07:32:28PM +0200, Jakub Jelinek wrote:
> Ok, I've tried that, but that doesn't work, it ICEs on the
> pr114574-2.c testcase.
The following works on quick testing of dg.exp=pr11[45]*.c
but haven't bootstrapped/regtested it yet.
2024-06-19 Jakub J
On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote:
> Ok. Then should it, instead of
>
> TYPE_CANONICAL (x)
> = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> be
>
> tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> TYPE_CANONICAL (x) =
On Wed, Jun 19, 2024 at 09:36:40AM +0200, Richard Biener wrote:
> > TYPE_CANONICAL (x)
> > = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> That looks indeed weird. What are the constraints on 't' for
> c_update_type_canonical? If it is TYPE_STRUCTURAL_EQUALITY_P
> the
On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote:
> Ok. Then should it, instead of
>
> TYPE_CANONICAL (x)
> = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> be
>
> tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> TYPE_CANONICAL (x) =
On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> >> Note a canonical type should always be unqualified (for
> >> classical qualifiers, not address space or atomic qualification)
> >
> > The logic in build_qualified_type is the same as in this patch,
> > it constructs
be included in the data etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-18 Jakub Jelinek
libcpp/
* internal.h (struct cpp_embed_params): Add offset member.
* directives.cc (_cpp_parse_embed_params): Parse gnu::offset
parameter
ft 6.10.3.2 in Example 4
if (f_source == NULL);
return 1;
(note the spurious semicolon after closing paren), has that been fixed
already?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-18 Jakub Jelinek
PR c/105863
libcpp/
* include/cpplib.h: Implement
On Mon, Jun 17, 2024 at 09:09:37PM +0200, Andreas Krebbel wrote:
> On 6/14/24 20:03, Jakub Jelinek wrote:
> > Also wonder about the
> > // { dg-additional-options "-march=z14" { target s390*-*-* } }
> > line, doesn't that mean the test will FAIL on all pre-z1
tes to 207572 bytes.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
2024-06-17 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Change
declaration of rs6000_init_generated_builtins from no arguments
to 4 pointer argume
he following patch adds ()s around the operand as well, but does
that only for non-decls, for decls keeps it as [0] like before.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and release branches?
2024-06-17 Jakub Jelinek
PR c/115290
* c-warn.cc (do_warn_a
or _Float32 vs. double also returned they have the same rank.
Committed to trunk as obvious, will backport to 14/13 soon.
2024-06-17 Jakub Jelinek
PR target/111343
PR c++/115511
* typeck.cc (cp_compare_floating_point_conversion_ranks): If an
extended floating poin
true },
and
{ "--std", "", "-std=", false, false },
use non-NULL opt1. That says that
--machine foo
should map to
-mfoo
and
--machine no-foo
should map to
-mno-foo
and
--std c++17
should map to
-std=c++17
add_misspelling_canidates was not handling this, so it hapilly
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
patch. While the committed and backported patch fixed PCH on PIE
cc1/cc1plus etc. on PowerPC, it grew up the size of the
rs6000_init_generated_builtins function quite a lot.
The above patch decreases it
On Sat, Jun 15, 2024 at 09:47:04PM +0200, Gerald Pfeifer wrote:
> There should be *very* few user visible changes such as new options or
> substantially different behaviors on release branches - pretty much by
> definition.
In reality there are tons of changes, people add new options even on
rget, or
check in main (in that case copied over to g++.target/s390) whether
z14 instructions can be actually used at runtime?
Tested on x86_64-linux, committed to trunk as obvious.
2024-06-14 Jakub Jelinek
* g++.dg/torture/vshuf-mem.C: Add -Wno-psabi to dg-options.
--- gcc/testsuite/
paren), has that been fixed
already?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-14 Jakub Jelinek
PR c/105863
libcpp/
* include/cpplib.h: Implement C23 N3017 #embed - a scannable,
tooling-friendly binary resource inclusion mechani
On Tue, Jun 11, 2024 at 10:40:01PM +0800, liuhongt wrote:
> gcc/ChangeLog:
>
> PR target/115384
> * simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
> Only do the simplification of (AND (ASHIFTRT A imm) mask)
> to (LSHIFTRT A imm) when the component of
On Tue, Jun 11, 2024 at 10:06:49AM +0200, Richard Biener wrote:
> > approrpiate #define _POSIX_C_SOURCE or #define _XOPE_SOURCE befor the
> > include in case somebody builds with -std=c99?
>
> Oh, and the manpage says that also defines ssize_t which
> is a bit odd since we already include that
On Tue, Jun 11, 2024 at 09:27:37AM +0200, Richard Biener wrote:
> On Tue, 11 Jun 2024, FX Coudert wrote:
>
> > Hi
> >
> > I can’t seem to get a review of this one-line patch. Could a global
> > reviewer help?
>
> While stdio.h can be relied on to exist I do not think you can assume
> the same
On Tue, Jun 11, 2024 at 01:36:35PM +0800, liuhongt wrote:
> In theory, const_wide_int can also be handle with extra check for each
> components of the HOST_WIDE_INT array, and the check is need for both
> shift and bit_and operands.
> I assume the optimization opportnunity is rare, so the patch
On Wed, Mar 06, 2024 at 06:08:47PM +0100, Frederik Harwath wrote:
> Subject: [PATCH] OpenMP: warn about iteration var modifications in loop body
Note, the partially rewritten OpenMP loop transformations changes are now
in.
See below.
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -235,6
all ones value and as long as it repeated in another limb above it
it would be ok.
So, the optimization just can't work properly and the following patch
removes it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/14.2?
2024-06-07 Jakub Jelinek
PR middle-e
Hi!
The implementation has been committed in r15-1037.
2024-06-06 Jakub Jelinek
* libgomp.texi (OpenMP 5.1 status): Mark Loop transformation constructs
as implemented.
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -302,7 +302,7 @@ The OpenMP 4.5 specification is fully
On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote:
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool
> hiding, bool was_hidden)
> retrofit_lang_decl (newdecl);
> tree alias = DECL_LOCAL_DECL_ALIAS
?
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p): Handle
CASE_CFN_CTZ like CASE_CFN_CLZ.
--- gcc/fold-const.cc.jj2024-06-04 12:08:14.671262211 +0200
+++ gcc/fold-const.cc 2024-06-04 10:56:57.575425348 +0200
] or similar.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* gimple-range-op.cc (cfn_clz::fold_range): For
m_gimple_call_internal_p handle as a special case also second argument
of -1 next
Hi!
While looking into PR115337, I've spotted some badly formatted code,
which the following patch fixes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
* fold-const.cc (tree_call_nonnegative_warnv_p): Formatting fixes
the testcase and the fold-const.cc change
would need to differentiate between __builtin_clz* vs. .CLZ and in the
latter case look at CLZ_DEFINED_VALUE_AT_ZERO.
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p) :
If arg1
On Wed, May 29, 2024 at 04:09:08AM +, user202...@protonmail.com wrote:
> This patch implements the flag -fassume-sane-operator-new as suggested in
> PR110137. When the flag is enabled, it is assumed that operator new does not
> modify global memory.
>
> While this patch is not powerful
On Tue, Jun 04, 2024 at 11:58:43AM +0100, Andre Vieira (lists) wrote:
> case annot_expr_unroll_kind:
> + case annot_expr_interleaves_kind:
> {
> - pp_string (pp, ", unroll ");
> + pp_string (pp,
> +annot_expr_unroll_kind
I think
e 4 arrays as arguments to the function from the caller.
This decreases the function size from 228668 bytes to 207572 bytes.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): C
_64-linux and i686-linux, ok for trunk and
release branches?
2024-06-04 Jakub Jelinek
PR c/114493
* c-decl.cc (c_fixup_may_alias): New function.
(finish_struct): Call it if "may_alias" attribute is
specified.
* gcc.dg/pr114493-1.c: New test.
and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr
On Mon, Jun 03, 2024 at 07:02:00PM +0200, Michael Matz wrote:
> Hello,
>
> On Fri, 31 May 2024, Andi Kleen wrote:
>
> > > I think the ultimate knowledge if a call can or cannot be implemented as
> > > tail-call lies within calls.cc/expand_call: It is inherently
> > > target and ABI specific
On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote:
> On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote:
> > > @@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
> > > attr_ns)
> > > /* Maybe we don't expect to see any arguments for this attribute.
is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
Bootstrapped/regtest
On Mon, Jun 03, 2024 at 05:41:11PM +0800, Kewen.Lin wrote:
> > GCN does have some partially implemented support for HFmode ... do I need
> > to do something new for that to work?
>
> For this hook, no, as it's mainly for float, double and long double types (C
> language supported non decimal
On Sat, Jun 01, 2024 at 09:21:53AM +0100, Jonathan Wakely wrote:
> On Fri, 31 May 2024 at 18:43, Alexandre Oliva wrote:
> >
> > On May 31, 2024, Alexandre Oliva wrote:
> >
> > >> So either don't change this line at all, or just do a simple
> > >> s/__clang__/_GLIBCXX_CLANG/
> >
> > > If
On Fri, May 31, 2024 at 08:45:54AM +0100, Richard Sandiford wrote:
> > When you say same way, do you mean the way SVE ABI defines the rules for
> > SVE types?
>
> No, sorry, I meant that if the choice isn't purely local to a source
> code function, the condition should be something like
On Wed, May 29, 2024 at 08:20:01AM +0200, Tobias Burnus wrote:
> + if (num_devices > 0
> + && (omp_requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY))
> +for (int dev = 0; dev < num_devices; dev++)
> + {
> + int pi;
> + CUresult r;
> + r = CUDA_CALL_NOCHECK
On Wed, May 29, 2024 at 02:15:07PM +0200, Tobias Burnus wrote:
> + bool b;
> + hsa_status_t status;
> + status = hsa_fns.hsa_system_get_info_fn (
> + HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT, );
> + if (status != HSA_STATUS_SUCCESS)
> + GOMP_PLUGIN_error (
On Wed, May 29, 2024 at 08:49:01AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > I mean, if we want to add something, maybe better would an -include like
> > option that instead of including a file includes it directly.
> > gcc --include-inline '#pragma omp requires
On Wed, May 29, 2024 at 08:41:04AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > How is that option different from
> > echo '#pragma omp requires unified_shared_memory' > omp-usm.h
> > gcc -include omp-usm.h
> > ?
> > I mean with -include you can
On Wed, May 29, 2024 at 08:26:04AM +0200, Jakub Jelinek wrote:
> > *I am especially thinking about a global variable and "#pragma omp declare
> > target". At least with 'omp requires self_maps' of OpenMP 6, it seems as if
> > 'declare target enter(global_var)' sh
On Tue, May 28, 2024 at 09:23:41PM +0200, Tobias Burnus wrote:
> -fopenmp-force-usm can be useful for some badly written code. Explicity
> using 'omp requires' makes more sense but still. It might also make sense
> for testing purpose.
>
> Unfortunately, I did not see a simple way of testing it.
On Tue, May 28, 2024 at 07:43:00PM +0200, Tobias Burnus wrote:
> Improve test coverage by removing 'prune-output' given that the features are
> implemented in the meanwhile.
>
> Comments, suggestions? Otherwise I will commit the patch as obvious.
>
> Tobias
> testsuite/*/gomp: Remove
On Mon, May 27, 2024 at 11:11:43AM +0200, Richard Biener wrote:
> For the following testcase we fail to demangle
> _ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnernwEm and
> _ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnerdlEPv and in turn end
> up building NULL references. The following puts in a
is still built, it isn't added in
-L options).
Ok for 13 branch?
I think the r13-8067 cherry-pick hasn't been applied to 12 branch,
so we don't need it there.
2024-05-27 Jakub Jelinek
* testsuite/19_diagnostics/stacktrace/hash.cc: Adjust
dg-options to use -lstdc++exp
On Fri, May 24, 2024 at 05:39:45PM +0200, Martin Uecker wrote:
> PR 115157
> PR 115177
>
> gcc/c/
> * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum,
> finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL.
> * c-obj-common.cc
On Wed, May 22, 2024 at 05:23:33PM +0800, YunQiang Su wrote:
> Jakub Jelinek 于2024年5月22日周三 17:14写道：
> >
> > On Wed, May 22, 2024 at 05:05:30PM +0800, YunQiang Su wrote:
> > > > --- gcc/gcc.cc.jj 2024-02-09 14:54:09.141489744 +0100
> > > > +++ gcc/gcc.
On Wed, May 22, 2024 at 05:05:30PM +0800, YunQiang Su wrote:
> > --- gcc/gcc.cc.jj 2024-02-09 14:54:09.141489744 +0100
> > +++ gcc/gcc.cc 2024-02-09 22:04:37.655678742 +0100
> > @@ -2410,8 +2410,7 @@ read_specs (const char *filename, bool m
> > if (*p1++ != '<' || p[-2] !=
On Wed, May 22, 2024 at 09:46:41AM +0200, Richard Biener wrote:
> On Wed, May 22, 2024 at 3:58 AM liuhongt wrote:
> >
> > According to IEEE standard, for conversions from floating point to
> > integer. When a NaN or infinite operand cannot be represented in the
> > destination format and this
infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk and affected release branches?
2024-05-
, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk and release branches?
2024-05-21 Jakub Jelinek
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
On Tue, May 21, 2024 at 09:36:05AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> > > Hmm, there were now two daily bumps: [...] I really wonder why.
> > Because I've done it by hand.
>
> Okay,
On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> Hmm, there were now two daily bumps:
>
> Date: Mon May 20 00:16:30 2024 +
>
> Date: Sun May 19 18:15:28 2024 +
>
> I really wonder why.
Because I've done it by hand.
I have in ~gccadmin a gcc-changelog copy and
On Sat, May 18, 2024 at 02:53:20PM +0800, Kefu Chai wrote:
> libstdc++-v3/ChangeLog:
>
> * include/bits/unicode.h (enable_borrowed_range): Call ++(*this)
> instead of ++this
This should be already fixed, see https://gcc.gnu.org/PR115119
Jakub
On Fri, May 03, 2024 at 11:08:04AM -0600, Tom Tromey wrote:
> DWARF is not especially clear on the distinction between
> DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
> more appropriate for Ada. This patch changes the compiler to do this.
> Note that the Ada compiler does
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651199.html
patch.
Thanks.
On Thu, May 09, 2024 at 08:12:30PM +0200, Jakub Jelinek wrote:
> The C++26 P2662R3 Pack indexing paper mentions that both GCC
> and MSVC don't handle T...[10] parameter declaration
On Thu, May 16, 2024 at 12:14:09PM +0200, Aldy Hernandez wrote:
> Wait, what's the preferred way of reverting a patch? I followed what I saw
> in:
Reverting a patch (that isn't a reversion) just push git revert.
The important part is not to modify the This reverts commit line from what
git
On Thu, May 16, 2024 at 12:01:01PM +0200, Aldy Hernandez wrote:
> This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables
> prange
> support again.
Please don't do this.
This breaks ChangeLog generation, will need to handle it tomorrow by hand again.
Both the ammendments to the
with reduction clause(s).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2024-05-15 Jakub Jelinek
PR c/115103
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/cp
to tell callers the comparison is now unconditional).
The following patch just disables the optimization in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, preapproved by
Segher in the PR, committed to trunk so far.
2024-05-15 Jakub Jelinek
PR rtl-optimization/114902
On Wed, May 15, 2024 at 01:41:04PM +0200, Richard Biener wrote:
> PR middle-end/111422
> * cfgexpand.cc (add_scope_conflicts_2): Handle PHIs
> by recursing to their arguments.
> ---
> gcc/cfgexpand.cc | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
On Tue, May 07, 2024 at 10:37:55AM +0800, HAO CHEN GUI wrote:
> The former patch adds isfinite optab for __builtin_isfinite.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
>
> Thus the builtin might not be folded at front end. The range op for
> isfinite is needed for
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
>
> This happens because we expect to match:
> ...
> .byte 0xb # Define macro strx
> ...
> but
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
>
> This happens because we expect to match:
> ...
> .byte 0xb # Define macro strx
> ...
> but
On Tue, May 14, 2024 at 01:35:30PM +0200, Tom de Vries wrote:
> Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and
> -g3:
> ...
> $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
> ...
>
> In section .debug_macro.dwo, we have:
> ...
>
On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
> > 2024-05-09 Jakub Jelinek
> > Jason Merrill
> >
> > PR lto/113208
> > * cp-tree.h (maybe_optimize_cdtor): Remove.
> > * decl2.cc (tentative_decl_linkage): Call mayb
On Thu, May 09, 2024 at 01:42:15PM -0400, David Malcolm wrote:
> I've pushed the following changes to releases/gcc-13
> as r13-8741-g89feb3557a0188 through r13-8761-gb7a2697733d19a.
Unfortunately many of the commits contained git commit message wording
that update_git_version can't cope with.
linux, ok for trunk?
2024-05-13 Jakub Jelinek
PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith
On Thu, May 09, 2024 at 02:58:52PM -0400, Marek Polacek wrote:
> On Thu, May 09, 2024 at 08:20:00PM +0200, Jakub Jelinek wrote:
> > --- gcc/cp/decl.cc.jj 2024-05-09 10:30:54.804505130 +0200
> > +++ gcc/cp/decl.cc 2024-05-09 17:07:08.400110018 +0200
> >
sts for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.
Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=pr84508*
ubsan.exp=pr84508*'
and committed to trunk as obvious.
2024-05-09 Jakub Jel
, we can cast always to
get_cxa_atexit_fn_ptr_type () type, because this is in use_dtor guarded code
and use_dtor is ob_parm && CLASS_TYPE_P (type), so when use_dtor is true,
ob_parm is also true.
Ok for trunk if it passes another bootstrap/regtest?
2024-05-09 Jakub Jelinek
PR target/11
CC 14 and delay this approach to 15. Your v1 patch is OK for 14.
Ok, here is an updated patch, which sets DECL_SAVED_TREE to void_node for
the aliases together with reversion of the earlier committed patch.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-09
in cp_parser_direct_declarator.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-09 Jakub Jelinek
PR c++/115012
* parser.cc (cp_parser_direct_declarator): Handle
abstract declarator starting with ... followed by [
or (.
* g++.dg/cpp0x
On Thu, May 09, 2024 at 12:14:43PM +0200, Jakub Jelinek wrote:
> On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> > I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> > staying at 20240507.
>
> I think it is because of the r15-268
On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> staying at 20240507.
I think it is because of the r15-268 commit, we do support
This reverts commit ...
when the referenced commit contains a ChangeLog message,
after testing it on x86_64-linux with
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32/-mno-sse,-m32,-m64\}
dg-torture.exp=vector-subaccess-1.C'
and backported all the way to 11 branch.
2024-05-09 Jakub Jelinek
PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno
for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.
Bootstrapped/regtested on x86_64-linux and i686-linux and Liu Hao tested
it on mingw32, ok for trunk?
2024-05-09 Jakub Jelinek
PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit
<= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
Bootstrapped/regtested on x86_64-linux and i686-linux,
On Tue, May 07, 2024 at 08:57:00PM +0200, Richard Biener wrote:
>
>
> > Am 07.05.2024 um 18:02 schrieb Jakub Jelinek :
> >
> > Hi!
> >
> > The HF and BF modes have the same size/precision and neither is
> > a subset nor superset of the other.
> >
to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-07 Jakub Jelinek
PR middle-end/114907
* expr.cc (convert_mode_scalar): Use
only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.
Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-07 Jakub Jelinek
On Tue, May 07, 2024 at 02:12:07PM +0100, Andre Vieira (lists) wrote:
> Hey Jakub,
>
> This what ya had in mind?
Yes.
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index
> ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1
> 100644
>
On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote:
> > TYPE_CANONICAL as used by the middle-end cannot express this but
>
> Hm. so how does it work now for arrays?
Do you have a testcase which doesn't work correctly with the arrays?
E.g. same_type_for_tbaa has
type1 =
On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
> A change that is not optimal but would avoid a lot of trouble is to
> only use the tag of the struct for computing a TYPE_CANONICAL, which
> could then be set already for incomplete types and never needs to
> change again. We would
On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote:
> Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
> > to make sure to include that into the type unification done via
> > type_hash_canon. This
oop to parse the further friend type
specifiers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-03 Jakub Jelinek
PR c++/114459
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_variadic_friend=202403L for C++26.
gcc
On Fri, May 03, 2024 at 04:06:28PM +0100, Jonathan Wakely wrote:
> I agree it should be mentioned, but I would put it in the caveats
> section at the top, not as the last item of the C section.
>
> How about this? OK for wwwdocs?
LGTM.
> commit fe5fd75ea5a7a08eee0831cadbdd05689e9408db
> Author:
On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote:
> Jakub, Richi, Rainer: this is a non-trivial change that cleans up
> analyzer C++ testsuite results on Solaris, but has a slight risk of
> affecting analyzer behavior on other targets. As such, I was thinking
> to hold off on
On Fri, May 03, 2024 at 12:58:55PM +0200, Richard Biener wrote:
> When building a type and type_hash_canon returns an existing type
> avoid changing it, in particular its TYPE_CANONICAL.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
>
> OK for trunk?
>
> Thanks,
>
or
not, it just fixes the behavior when we inline them despite those checks.
The stack save/restore restores the behavior that alloca acquired regions
are freed at the end of the containing call.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-03 Jakub Jelinek
PR
On Thu, May 02, 2024 at 12:52:59PM -0700, Ken Matsui wrote:
> > This seems to be the prevailing sentiment, so let's continue that way.
> > Thanks for the input.
>
> I actually found that we have two built-in type traits prefixed with
> __builtin: __builtin_is_corresponding_member and
That is a
On Thu, May 02, 2024 at 01:53:21PM +0100, Iain Sandoe wrote:
> My testing of the GCC-14 release branch revealed an Objective-C
> regression in code-gen, the fix has been tested on x86_64, i686
> and powerpc darwin, pushed to trunk.
>
> I will shortly apply this to the open branches, since they
1 - 100 of 19050 matches
Mail list logo
