med_args to be number of named arguments except the last, then that
should be 0 rather than 1.
Thus, is the following patch ok for trunk then?
2024-02-29 Jakub Jelinek
PR target/107453
* calls.cc (expand_call): For TYPE_NO_NAMED_ARGS_STDARG_P set
n_named_args initial
On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote:
> I am not wed to the idea (just it appeared to me as an option to
> disabling this optimization by default). I still think it may make sense.
Maybe I misunderstood your idea.
So, you are basically suggesting to go in a completely
On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote:
> I agree that debugability of user core dumps is important here.
>
> I guess an ideal solution would be to change codegen of noreturn functions
> to callee save all registers. Performance of prologue of noreturn
> function is not too
On Thu, Feb 29, 2024 at 02:08:19PM +0100, Richard Biener wrote:
> > So, wouldn't it be better to outline what you have above + POLY_INT_CST
> > handling into a helper function, which similarly to get_range_pos_neg
> > returns a bitmask, but rather than 1 bit for may be [0, max] and another
> >
On Thu, Feb 29, 2024 at 04:26:00AM -0800, H.J. Lu wrote:
> > > Adding Hongtao and Honza into the loop as the ones who acked the original
> > > patch.
> > >
> > > The no_callee_saved_registers by default for noreturn functions change can
> > > break in-process backtrace(3) or backtraces from
, ...).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-29 Jakub Jelinek
PR debug/114015
* dwarf2out.cc (should_move_die_to_comdat): Return false for
aggregates without DW_AT_byte_size attribute or with non-constant
DW_AT_byte_size.
* gcc.dg
else
/* Expr is a reference variable for the tuple case. */
return lookup_decomp_type (expr);
2024-02-29 Jakub Jelinek
PR c++/92687
* decl.cc (cp_finish_decomp): If processing_template_decl, remember
whether std::tuple_{size,element} wil
On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote:
> That said, the quick experiment shows this isn't anything for stage4.
The earlier the vector lowering is moved in the pass list, the higher
are the possibilities that match.pd or some other optimization reintroduces
unsupportable
On Thu, Feb 29, 2024 at 09:21:02AM +0100, Richard Biener wrote:
> The following switches the logic in chrec_fold_multiply to
> get_range_pos_neg since handling POLY_INT_CST possibly mixed with
> non-poly ranges will make the open-coding awkward and while not
> a perfect fit it should work.
>
> In
On Wed, Feb 28, 2024 at 11:15:10AM +, Jonathan Wakely wrote:
> I'd like to be able to link directly to this part of the page from other
> docs.
>
> OK for wwwdocs?
LGTM.
> diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
> index c89cdb8f..54f8005a 100644
> --- a/htdocs/gitwrite.html
On Tue, Feb 27, 2024 at 01:40:09PM +, Andre Vieira (lists) wrote:
> Dropped the first patch and dealt with the comments above, hopefully I
> didn't miss any this time.
>
> --
>
> This patch adds support for C23's _BitInt for the AArch64 port when
> compiling
>
as the comment explains.
Tested in a cross to powerpc64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
tree-ssa.exp=ssa-sink-18.c'
and committed to trunk as obvious.
2024-02-28 Jakub Jelinek
PR testsuite/111462
* gcc.dg/tree-ssa/ssa-sink-18.c: XFAIL also
Hi!
This adds testcase from PR114075 which has been fixed by the r14-9205
change on s390x-linux with -march=z13.
Tested on x86_64-linux -m32/-m64 and using a cross to s390x-linux
before/after r14-9205 with subsequent execution on s390x hw.
Committed to trunk as obvious.
2024-02-28 Jakub
Hi!
Adding Hongtao and Honza into the loop as the ones who acked the original
patch.
The no_callee_saved_registers by default for noreturn functions change can
break in-process backtrace(3) or backtraces from debugger or other process
(quite often, any time the noreturn function decides to use
On Wed, Feb 28, 2024 at 09:27:10AM +0100, Richard Biener wrote:
> I guess the int_mode_for_size (ilen * BITS_PER_UNIT, 0).exists ()
> could then be removed in stage1?
Yes, that's the plan. I'll make a note in my stage1 todo list.
Jakub
On Tue, Feb 27, 2024 at 06:54:49PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 06:25:21PM +0100, Jakub Jelinek wrote:
> > I guess we need some testsuite coverage for caller/callee ABI match of
> > struct S { char p[64]; };
> > struct S foo (...);
>
> Ma
On Wed, Feb 28, 2024 at 08:58:08AM +0100, Richard Biener wrote:
> Incidentially this looks like something fit for a google summer of code
> project.
> Ideally it would hook into print-tree.cc providing an alternate
> structured output.
> It currently prints in the style
>
> type
ion, but the add_conditions_to_domain check
for INTEGER_TYPE remained.
The following patch uses INTEGRAL_TYPE_P to complete the change.
Bootstrapped/regtested on x86_64-linux and i686-linux (--with-isl only
on the former though), ok for trunk?
2024-02-28 Jakub Jelinek
PR tree-optimization/114
On Tue, Feb 27, 2024 at 03:57:52PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 01:09:09PM +0100, Jakub Jelinek wrote:
> > So, IMHO either revert the changes altogether, or guard on -mcmodel=kernel
> > (but talk to kernel people on linux-toolchains if that is what they ac
hem,
perhaps misaligned moves and that is it, so they pose problems e.g. to
BITINT_TYPE lowering.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-28 Jakub Jelinek
PR tree-optimization/113988
* stor-layout.h (bitwise_mode_for_size): Decl
On Tue, Feb 27, 2024 at 06:25:21PM +0100, Jakub Jelinek wrote:
> I guess we need some testsuite coverage for caller/callee ABI match of
> struct S { char p[64]; };
> struct S foo (...);
Maybe the test below? Passes on x86_64 -m32/-m64, but I guess that doesn't
care at all about the
On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote:
> > 2023-01-09 Jakub Jelinek
> >
> > PR target/107453
> > * calls.cc (expand_call): For calls with
> > TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args.
> > Fo
On Tue, Feb 27, 2024 at 01:09:09PM +0100, Jakub Jelinek wrote:
> So, IMHO either revert the changes altogether, or guard on -mcmodel=kernel
> (but talk to kernel people on linux-toolchains if that is what they actually
> want).
Here is a patch which guards this by non-default option,
On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote:
> For __libc_start_main, glibc surely just could use no_callee_saved_registers
> attribute, because that is typically the outermost frame in backtrace,
> there is no need to save those there.
> And for kernel if it
On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 10:04:06AM +0100, Jakub Jelinek wrote:
> > > I hope we at least avoid that at -O0, possibly also with -Og?
> >
> > r14-8495 fixed at least that.
> >
> > Of course, it can
On Tue, Feb 27, 2024 at 10:04:06AM +0100, Jakub Jelinek wrote:
> > I hope we at least avoid that at -O0, possibly also with -Og?
>
> r14-8495 fixed at least that.
>
> Of course, it can break debugging experience even when the noreturn function
> is compiled with -O2 bu
On Tue, Feb 27, 2024 at 09:54:45AM +0100, Richard Biener wrote:
> Just to add we've in the past opted to avoid tail-calling abort () and friends
> exactly to help debugging. So treating noreturn functions specially with
> respect to caller saves looks inconsistent in this regard - it makes
On Tue, Feb 27, 2024 at 09:51:05AM +0100, Richard Biener wrote:
> On Tue, 27 Feb 2024, Jakub Jelinek wrote:
>
> > On Tue, Feb 27, 2024 at 09:35:43AM +0100, Richard Biener wrote:
> > > I do wonder whether we can handle the missing LHS case generically
> > > in the
On Tue, Feb 27, 2024 at 09:35:43AM +0100, Richard Biener wrote:
> I do wonder whether we can handle the missing LHS case generically
> in the direct optab expander for fns that are PURE or CONST?
Maybe the 2 operand expand_internal_call could do it before handing over
to individual expanders.
and i686-linux, ok for trunk?
2024-02-27 Jakub Jelinek
PR target/114116
* config/i386/i386.h (enum call_saved_registers_type): Add
TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP enumerator.
* config/i386/i386-options.cc (ix86_set_func_type): Remove
/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-27 Jakub Jelinek
PR rtl-optimization/114044
* internal-fn.def (CLRSB, CLZ, CTZ, FFS, PARITY): Use
DEF_INTERNAL_INT_EXT_FN macro rather than DEF_INTERNAL_INT_FN.
* internal-fn.h (expand_CLRSB
On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote:
> When folding a multiply CHRECs are handled like {a, +, b} * c
> is {a*c, +, b*c} but that isn't generally correct when overflow
> invokes undefined behavior. The following uses unsigned arithmetic
> unless either a is zero or a and
On Mon, Feb 26, 2024 at 04:51:08PM +0100, Michael Matz wrote:
> On Mon, 26 Feb 2024, Jakub Jelinek wrote:
>
> > > Will update the patch, I think any improvement should be done
> > > to get_range_pos_neg (it's a bit odd in behavior for unsigned
> > > but I
On Mon, Feb 26, 2024 at 03:29:30PM +0100, Richard Biener wrote:
> On Mon, 26 Feb 2024, Jakub Jelinek wrote:
>
> > On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote:
> > > When folding a multiply CHRECs are handled like {a, +, b} * c
> > > is {a*c, +,
On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote:
> When folding a multiply CHRECs are handled like {a, +, b} * c
> is {a*c, +, b*c} but that isn't generally correct when overflow
> invokes undefined behavior. The following uses unsigned arithmetic
> unless either a is zero or a and
Hi!
I'd like to ping 2 patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html
PR113617 P1 - Handle private COMDAT function symbol reference in readonly data
On Mon, Feb 26, 2024 at 09:53:41AM +0100, Richard Biener wrote:
> On Mon, 26 Feb 2024, Jakub Jelinek wrote:
>
> > On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote:
> > > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo,
> > >
On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote:
> > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo,
> > >those through even when the mode isn't word_mode. For
> > >ops we have to lower the lowering code assumes we are
> > >dealing with word_mode. */
>
&& !TYPE_OVERFLOW_SANITIZED (type) because
in both simplifications there would be UB before and after on
signed integer minimum.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-26 Jakub Jelinek
PR tree-optimization/114090
* match.pd ((x >= 0 ? x : 0) + (
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-26 Jakub Jelinek
PR middle-end/114084
* fold-const.cc (fold_binary_loc): Avoid the final associate_trees
if all subtrees of var0 come from one of the op0 or op1 operands
and all subtrees of co
linux and i686-linux,
committed to trunk as obvious.
2024-02-26 Jakub Jelinek
PR target/114094
* config/i386/i386.cc (x86_function_profiler): Add missing new-line
to printed instruction.
* gcc.target/i386/pr114094.c: New test.
--- gcc/config/i386/i386.cc.
the
left shift was done in HOST_WIDE_INT type but assigned to unsigned
HOST_WIDE_INT, which I've changed into unsigned HOST_WIDE_INT shift.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-24 Jakub Jelinek
gcc/
* builtins.cc (fold_builtin_isascii): Use
Hi!
The following patch implements support for VIEW_CONVERT_EXPRs from/to
large/huge _BitInt to/from vector or complex types or anything else but
integral/pointer types which doesn't need to live in memory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-24 Jakub
On Fri, Feb 23, 2024 at 02:43:45PM +0100, Juergen Christ wrote:
> The emulation via word mode tries to perform integer arithmetic on floating
> point values instead of floating point arithmetic. This leads to
> mis-compilations.
>
> Failure occured on s390x on these existing test cases:
>
On Fri, Feb 23, 2024 at 02:22:19PM +, Andrew Stubbs wrote:
> On 23/02/2024 13:02, Jakub Jelinek wrote:
> > On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
> > > This is a follow-up to the previous patch to ensure that integer vector
> > > bit-masks
On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote:
> This is a follow-up to the previous patch to ensure that integer vector
> bit-masks do not have excess bits set. It fixes a bug, observed on
> amdgcn, in which the mask could be incorrectly set to zero, resulting in
> wrong-code.
>
On Fri, Feb 23, 2024 at 12:25:54PM +0100, Tobias Burnus wrote:
> When checking something else, I noticed that there was one warning in
> openmp.cc that did not use OPT_Wopenmp.
>
> I intent to commit the attached patch later today as obvious.
>
> Tobias
> Fortran/Openmp: Use OPT_Wopenmp for
this.
Christophe, do you think you could test this? Thanks.
2024-02-23 Jakub Jelinek
PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
* g++.dg/cpp0x/constexpr
24-02-23 Jakub Jelinek
PR rtl-optimization/114054
* expr.cc (expand_expr_real_2) : Use
temp variable instead of target parameter for result.
* gcc.dg/bitint-92.c: New test.
--- gcc/expr.cc.jj 2024-02-14 14:26:19.709811397 +0100
+++ gcc/expr.cc 2024-02-
hecks from check_builtin_function_arguments
which are there done on BUILT_IN_{CLZ,CTZ,POPCOUNT}G, such that they
diagnose it with the name of the "builtin" user actually used before it
is gone.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-23 Jakub Jelinek
PR
apped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-23 Jakub Jelinek
PR tree-optimization/114040
* gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
Use EQ_EXPR rather than LT_EXPR for g2 condition and change its
probabil
On Thu, Feb 22, 2024 at 12:59:18PM -0800, Greg McGary wrote:
> The sign bit of a sign-extending load cannot be known until runtime,
> so don't attempt to simplify it in the combiner.
>
> 2024-02-22 Greg McGary
>
> PR rtl-optimization/113010
> * combine.cc
On Thu, Feb 22, 2024 at 05:49:12PM +, Joseph Myers wrote:
> This patch (the one using COLON_SCOPE, *not* the one using PREV_WHITE) is
> OK.
>
> PREV_WHITE is about whether there is whitespace between the tokens in the
> macro expansion, for the purposes of stringization - I don't think it's
On Thu, Feb 22, 2024 at 04:35:22PM +0100, Michael Matz wrote:
> On Thu, 22 Feb 2024, Jakub Jelinek wrote:
>
> > > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag
> > > on
> > > the second COLON token to see that it's indeed a '::' with
On Thu, Feb 22, 2024 at 03:59:31PM +0100, Michael Matz wrote:
> Hello,
>
> On Thu, 22 Feb 2024, Jakub Jelinek wrote:
>
> > So, the following patch adds a flag during preprocessing at the point
> > where we normally create CPP_SCOPE tokens out of 2 consecutive colons
&g
? Or buffer[128]; and somehow prevent
arbitrarily long doubles? Or add size_t next to char * arguments and use
snprintf? Though, truncated messages would look ugly.
2024-02-22 Jakub Jelinek
PR ipa/111960
* profile-count.h (profile_count::dump): Remove overload with
= 1) for that, but cnt == 1 is never true here,
because cnt is either 2 or 3, so the right check is (cnt == 2).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-22 Jakub Jelinek
PR tree-optimization/114038
* gimple-lower-bitint.cc (bitint_large_h
t
form a valid preprocessing token, which is true, so just don't do that if
you try to have __STRICT_ANSI__ && __STDC_VERSION__ <= 201710L
compatibility.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-21 Jakub Jelinek
PR c/114007
gcc/
* d
On Wed, Feb 21, 2024 at 10:03:17AM +, Richard Sandiford wrote:
> In this PR, the SME mode-switching code needs to insert a stack-probe
> loop for an alloca. This patch allows the target to do that.
>
> There are two parts to it: allowing loops for insertions in blocks,
> and allowing them
imilar, no intent from me to look at that, that is preexisting issue.
BTW, I'm surprised we don't have BUILT_IN_EXP10F{16,32,64,128,32X,64X,128X}
builtins, seems glibc has those (sure, I think except *16 and *128x).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-21
On Tue, Feb 20, 2024 at 05:39:39PM +0100, Tobias Burnus wrote:
> clang/lib/Headers/openmp_wrappers/complex:device = {arch(amdgcn, nvptx,
> nvptx64)}, \
That one doesn't really need the nvptx64 support.
> --- a/gcc/config/nvptx/nvptx.cc
> +++
On Tue, Feb 20, 2024 at 11:11:22AM +0100, Richard Biener wrote:
> > --- gcc/c-family/c-common.cc.jj 2024-02-17 16:40:42.831571693 +0100
> > +++ gcc/c-family/c-common.cc2024-02-20 10:58:56.599865656 +0100
> > @@ -7793,9 +7793,14 @@ resolve_overloaded_atomic_exchange (loca
> >/*
nal so that the MEM_REFs don't appear that often in the
FE trees, but maybe that is fine.
The unconditional patch would then be:
2024-02-20 Jakub Jelinek
gcc/c-family/
* c-common.cc (resolve_overloaded_atomic_exchange): Instead of setting
p1 to VIEW_CONVERT_EXPR (*p1), s
cp_apply_type_quals_to_decl
on already instantiated variable declarations.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-19 Jakub Jelinek
Patrick Palka
PR c++/113976
* decl.cc (grokdeclarator): Don't call cp_apply_type_quals_to_decl
ABI [-Wpsabi]
Added -Wno-psabi to silence the warning.
Tested with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32/-march=i686,-m64\}
analyzer-torture.exp=vector-extract-1.c'
and committed to trunk as obvious.
2024-02-20 Jakub Jelinek
PR analyzer/113983
* gcc.dg/analy
On Tue, Feb 20, 2024 at 12:12:11AM +, Jason Merrill wrote:
> On 2/19/24 02:55, Jakub Jelinek wrote:
> > On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> > > Ah, although __atomic_compare_exchange only takes pointers, the
> > > compile
On Mon, Feb 19, 2024 at 04:13:29PM +, Andre Vieira (lists) wrote:
> Replaced uses of __seg_gs with the MACRO SEG defined in the testcase to pick
> (if any) the right __seg_{gs,fs} keyword based on target.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/bitint-86.c (__seg_gs): Replace with
into vectors,
but for BIT_FIELD_REF the position can be arbitrary if within the range.
The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2024-02-19 Jakub Jelinek
PR tree-optimization/113967
* match.pd (bit_insert @0
add support for MEM_REF in pt.cc, though with the assumption
that it has been already originally created with non-dependent
types/operands (which is the case here for the __atomic*exchange lowering).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-19 Jakub Jelinek
On Sat, Feb 17, 2024 at 10:15:55PM +0200, Dimitar Dimitrov wrote:
> When not optimized for speed, the test for PR112344 takes several
> seconds to execute on native x86_64, and 15 minutes on PRU target
> simulator. Thus mark those variants as expensive. The -O2 variant
> which originally
On Sat, Feb 17, 2024 at 09:59:12PM +0200, Dimitar Dimitrov wrote:
> On Fri, Feb 16, 2024 at 07:06:57PM +0100, Jakub Jelinek wrote:
> > On Fri, Feb 16, 2024 at 07:52:17PM +0200, Dimitar Dimitrov wrote:
> > > The issue in PR112344 is triggered only at -O2, so there is little valu
On Sat, Feb 17, 2024 at 04:05:16PM +0100, Harald Anlauf wrote:
> > +program pr113503
> > + implicit none
> > + type :: T
> > +character(len=:), allocatable :: u
> > + end type
> > + character(len=20) :: us(1) = 'foobar'
> > + type(T) :: x
> > + x = T(u = trim (us(1))) ! { dg-bogus "is
patch fixes it just by not messing up with
expr2->ts.u.cl->backend_decl, only set it to size variable and overwrite
that with a temporary if needed.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-17 Jakub Jelinek
PR fortran/113503
* trans
On Fri, Feb 16, 2024 at 10:47:47PM +0100, Jakub Jelinek wrote:
> The following patch works.
Or yet another option would be instead of (sometimes) clearing
declarator->parameter_pack_p when we diagnose this bug for error
recovery ignore the this specifier.
With the following patch (testsuite
On Fri, Feb 16, 2024 at 10:20:26PM +0100, Jakub Jelinek wrote:
> I've tried that (see below), but am getting
> Excess errors:
> /usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:33:29:
> error: parameter packs not expanded with '...':
And the reason for those
licit-obj-diagnostics3.C:149:38:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:152:33:
error: parameter packs not expanded with '...':
with it (the other errors are emitted as expected).
2024-02-16 Jakub Jelinek
PR c
works for C++, but C doesn't have anything
like that. All it uses is DECL_NAME == NULL on FIELD_DECL +
RECORD_OR_UNION_TYPE_P on its type to determine anon struct/union.
The patch below has updated cp_type_dwarf_attribute, otherwise the same as
before.
2024-02-16 Jakub Jelinek
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> > On 2/16/24 04:14, Jakub Jelinek wrote:
> > > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > > we emit
On Fri, Feb 16, 2024 at 07:52:17PM +0200, Dimitar Dimitrov wrote:
> The issue in PR112344 is triggered only at -O2, so there is little value
> in running the test at lower optimization levels. At the same time the
That is generally not true.
We had hundreds of cases in the history where a test
Hi!
Ah, and the reason why it doesn't work on target is that it has the
everything is mapped assumption:
if ((ctx->region_type & ORT_TARGET) != 0)
{
if (ctx->region_type & ORT_ACC)
/* For OpenACC, as remarked above, defer expansion. */
shared = false;
else
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> On 2/16/24 04:14, Jakub Jelinek wrote:
> > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > we emit it), but also on anonymous unions/structs (and we didn't emit tha
On Fri, Feb 16, 2024 at 04:15:05PM +0100, Tobias Burnus wrote:
> I have no idea whether that would - nor whether that would be
> the way forward. - Thoughts?
Don't have time to dive through this now in detail, just want to point out
why we ignore DECL_VALUE_EXPR on the magic var during
On Fri, Feb 16, 2024 at 02:23:54PM +, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Segher Boessenkool wrote:
>
> > > Conversely no heuristics is required to unwind VAX frames, because they
> > > are fixed in layout by hardware, fully self-described, and with the
> > > hardware frame
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding
On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
> FAIL:
|| nvptx-*-* for that?
2024-02-16 Jakub Jelinek
* lib/target-supports.exp (check_effective_target_lra): Rewrite
to list some heavily used always LRA targets and otherwise check the
-fdump-rtl-reload-details dump for messages specific to LRA.
--- gcc/testsuite/lib
ux, ok for trunk?
2024-02-16 Jakub Jelinek
PR c++/113929
* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
on template parameter declaration.
* g++.dg/parse/pr113929.C: New test.
--- gcc/cp/parser.cc.jj 2024-02-15 17:33:11.641453437 +0100
+
Hi!
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-16 Jakub
the diagnostics.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-16 Jakub Jelinek
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Don't emit
PR113307 diagnostics too early, instead for the
declarator->parameter_pack_p ca
on x86_64-linux, committed to trunk and other release branches.
Thanks to Andrew Pinski for noticing this on IRC.
2024-02-15 Jakub Jelinek
PR middle-end/107385
* gcc.dg/pr107385.c: Require lra effective target.
--- gcc/testsuite/gcc.dg/pr107385.c.jj 2024-02-15 15:51:24.171246580
Hi!
This testcase has been fixed by the PR113921 fix, but unlike testcase
in there this one is not target specific.
Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.
2024-02-15 Jakub Jelinek
PR middle-end/107385
* gcc.dg/pr107385.c: New test.
--- gcc
On Thu, Feb 15, 2024 at 11:00:29AM +0100, Richard Biener wrote:
> The following avoids recording BB dependences for debug stmt uses.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> It's unlikely a dependence is just because of debug stmts so
> actual compare-debug issues are
On Fri, Feb 09, 2024 at 11:03:38AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 07, 2024 at 12:43:59PM +0100, arthur.co...@embecosm.com wrote:
> > From: Philip Herron
> >
> > This patch introduces one regression because generics are getting better
> > understood ov
On Fri, Feb 09, 2024 at 11:03:38AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 07, 2024 at 12:43:59PM +0100, arthur.co...@embecosm.com wrote:
> > From: Philip Herron
> >
> > This patch introduces one regression because generics are getting better
> > understood ov
(fortunately
non-supported compilers aren't affected because GCC 11 was the first one
to support asm goto with outputs), in cfgexpand.cc it won't apply cleanly
due to the PR113415 fix, but manually applying it there will work.
2024-02-15 Jakub Jelinek
PR middle-end/113921
* cfgrtl.h
on x86_64-linux and i686-linux, ok for trunk?
2024-02-15 Jakub Jelinek
PR tree-optimization/113567
* gimple-lower-bitint.cc (gimple_lower_bitint): For large/huge
_BitInt multiplication, division or modulo with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs and at least one
s. LTO unnecessarily.
Bootstrapped/regtested on x86_64-linux and i686-linux.
2024-02-15 Jakub Jelinek
PR middle-end/113907
* ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
functions.
*
On Wed, Feb 14, 2024 at 07:59:26PM +, Iain Sandoe wrote:
> I have just one question;
>
> from your patch the use of endbr* seems to be unconditionally based on the
> flags used to build libgcc.
>
> However, I was expecting that the use of extended trampolines like this would
> depend on
On Wed, Feb 14, 2024 at 05:09:39PM +0100, Richard Biener wrote:
>
>
> > Am 14.02.2024 um 16:22 schrieb Jakub Jelinek :
> >
> > On Wed, Feb 14, 2024 at 04:13:51PM +0100, Richard Biener wrote:
> >> The following removes the TBAA violation present in iterativ
On Wed, Feb 14, 2024 at 04:13:51PM +0100, Richard Biener wrote:
> The following removes the TBAA violation present in iterative_hash.
> As we eventually LTO that it's important to fix. This also improves
> code generation for the >= 12 bytes loop by using | to compose the
> 4 byte words as at
801 - 900 of 21068 matches
Mail list logo
