On Wed, Mar 20, 2024 at 10:58:05AM -0600, Jeff Law wrote:
> On 3/20/24 10:06 AM, Jakub Jelinek wrote:
> > Like for x86-64, alpha or rs6000, m32r seems to be affected too.
> >
> > Just visually checked differences in c23-stdarg-9.c assembly in a cross
> > without/with th
nux and i686-linux, ok for trunk?
2024-03-21 Jakub Jelinek
PR libgcc/114397
* libgcc2.c (__divmodbitint4): Don't assume un < vn always means
abs(v) > abs(u), check for a special case of un + 1 == vn where
u is non-negative and v negative and after v&
On Thu, Mar 21, 2024 at 10:25:24AM +0100, Richard Biener wrote:
> The following more thoroughly avoids address sanitizing accesses
> to non-generic address-spaces.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> PR tree-optimization/111736
>
On Thu, Mar 21, 2024 at 10:50:04AM +0100, Richard Biener wrote:
> Fixed and pushed. I suppose for address-spaces nested within the
> generic address space we could instrument the address converted to
> the generic address space value.
Unlike TLS, we don't know if address-spaces are nested within
On Fri, Mar 22, 2024 at 01:00:21PM +0530, Ajit Agarwal wrote:
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each function
> is a stub that forwards the arguments to a real BLAS lib,
use 1 bit precision in that case. Also, it
used a wrong offset in that case.
The large testcase covers all these cases.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-22 Jakub Jelinek
PR tree-optimization/114405
* gimple-lower-bitint.cc
though they are still sanitized for -fsanitize=alignment.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-22 Jakub Jelinek
PR sanitizer/111736
* ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
SANITIZE_NULL instrumentation for non-
,
this patch doesn't change anything on that and I really don't know what
should be done in that case.
2024-03-22 Jakub Jelinek
PR c++/114409
* semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op with
TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if a
(long double)a) + (long double)5)
Still ugly and doesn't actually fix the FAIL (will deal with that
incrementally), but at least valid C/C++ and shows the excess precision
handling in action.
Ok for trunk if this passes bootstrap/regtest?
2024-03-22 Jakub Jelinek
gcc/c/
* c-prett
On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote:
> rs6000: Stackoverflow in optimized code on PPC [PR100799]
>
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each functi
n=fast,
so that the expression is always the same.
Tested on x86_64-linux -m32/-m64, committed to trunk.
2024-03-22 Jakub Jelinek
PR c++/112724
* c-c++-common/gomp/depobj-3.c: Add -fexcess-precision=fast as
dg-additional-options.
--- gcc/testsuite/c-c++-common/gomp/dep
On Fri, Mar 22, 2024 at 12:17:03PM -0600, Jeff Law wrote:
> I'd just make target_lra return false for nvptx rather than creating a new
The lra effective target currently though doesn't check if asm goto can have
outputs, but rather if the target is using lra.
> selector -- I'm not aware of any fe
code generation
for only the 2 new testcases according to statistics I've gathered.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-23 Jakub Jelinek
PR middle-end/111683
* tree-predcom.cc (pcom_worker::suitable_component_p): If has_write
MAGPART_EXPR of .ADD_OVERFLOW return value to some integral type.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-23 Jakub Jelinek
PR tree-optimization/114425
* gimple-lower-bitint.cc (build_bitint_stmt_ssa_conflicts): Handle
_Complex large/hug
check and only before returning
restored from the save_first copy.
Without this patch, we try to use the same SSA_NAME (_12 here) in 2
different PHI results which is obviously invalid IL and ICEs very quickly.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-23 Jakub
Hi!
I've committed the following patch to add the new CWG papers (and filed
corresponding bugzilla bugs).
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 65030980..bfef2114 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -
On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote:
> On 3/21/24 10:28 PM, Jason Merrill wrote:
> > On 3/21/24 16:48, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > OK.
>
> This started to break
>
> > $ cat test.cc
> > struct S1 { S1
On Tue, Mar 12, 2024 at 07:57:59PM +0800, liuhongt wrote:
> if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> alignb. (base_align_bias - base_offset) may not aligned to alignb, and
> caused segement fault.
>
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk an
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2 patch.
Thanks.
Jakub
Hi!
I've noticed a comment typo in x86-tune.def and cfgloopmanip.cc has the
same typo as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2024-03-26 Jakub Jelinek
* cfgloopmanip.cc (update_loop_exit_probability_scale_dom_bbs):
6_64-linux and i686-linux, ok for trunk?
2024-03-26 Jakub Jelinek
PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.
* gcc.dg/tsan/pr111736.c: New test.
--- gcc/tsan.cc.jj 2024-01-03 11:51:29.155764166 +0100
+++ g
arm.
2024-03-26 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc
he patch changes behavior and it is solely on the new testcase and
nothing else during the bootstrap/regtest. Ok for trunk?
2024-03-26 Jakub Jelinek
PR middle-end/51
* fold-const.cc (extract_muldiv_1) : Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.
I've added -Wno-psabi to dg-additional-options to fix that up.
Tested on x86_64-linux with
make check-gcc
RUNTESTFLAGS='--target_board=unix\{-m32/-mno-sse/-mno-mmx,-m32,-m64\}
dg-torture.exp=pr113126.c'
and committed to trunk as obvious.
2024-03-26 Jakub Jelinek
* gcc
-m32/-m64 with older and current trunk, committed
to trunk as obvious.
2024-03-26 Jakub Jelinek
PR middle-end/51
PR testsuite/114486
* gcc.c-torture/execute/pr51.c (main): Fix up expected value for
f.
--- gcc/testsuite/gcc.c-torture/execute/pr51.c.jj
On Tue, Mar 26, 2024 at 02:28:52PM +, Cupertino Miranda wrote:
> GCC was defining bts_offset entry to always contain 0.
> When comparing with clang, the same entry is instead a label to the
> respective variable or function. The assembler emits relocations for
> those labels.
>
> gcc/ChangeLog
ed on x86_64-linux and i686-linux, ok for trunk?
2024-03-26 Jakub Jelinek
PR tree-optimization/114469
* c-common.cc (resolve_overloaded_builtin): For _BitInt result
on !extended targets convert result to the _BitInt type before
using VIEW_CONVERT_EXPR.
--- gcc/c-f
.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-26 Jakub Jelinek
PR tree-optimization/114469
* match.pd ((view_convert (convert@0 @1))): Don't optimize if
TREE_TYPE (@0) is a BITINT_TYPE with padding bits which are supposed
to be
t for warnings, line 24)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 25)
on the latter and changes nothing on the former, ok for trunk?
2024-03-26 Jakub Jelinek
* lib/target-supports.exp (add_options_for_bfloat16): Add -msse2 on
i?86/x86_64.
etc.) rather
than literal S, say in %{S:X}. At least in HTML documentation it
then uses italics.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-26 Jakub Jelinek
* doc/invoke.texi (Spec Files): Use @var{S} instead of S,
@var{X} instead of X etc. for
On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
> > -/* The offset entry for each variable in a DATSEC should be 0 at compile
> > time. */
> > -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
> > +/* The offset entry fo
On Wed, Mar 27, 2024 at 12:48:29PM +0100, Richard Biener wrote:
> > The following patch attempts to fix the (view_convert (convert@0 @1))
> > optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
> > and @0 has the same precision as @1 and it has a different sign
> > and _BitInt with
On Wed, Mar 27, 2024 at 01:42:03PM +0100, Richard Biener wrote:
> The comment says it was added for (char)_Bool, probably
> gcc.dg/tree-ssa/vce-1.c will fail. But I'm not sure this optimization
> is important, it seems early SRA introduces a V_C_E here and then
> phiopt the conversion to unsigned
On Wed, Mar 27, 2024 at 04:42:21PM +0100, Richard Biener wrote:
> PR middle-end/114480
> * cfganal.cc (compute_idf): Use simpler bitmap iteration,
> touch work_set only when phi_insertion_points changed.
> ---
> gcc/cfganal.cc | 10 +++---
> 1 file changed, 3 insertions(+), 7
On Wed, Mar 27, 2024 at 07:44:28PM +0100, Michael Matz wrote:
> Hey,
>
> On Wed, 27 Mar 2024, Jakub Jelinek wrote:
>
> > > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> > >gcc_checking_assert (bb_index
> >
rob is required to be [0, 1] and if m_val is near the max_count,
it can overflow even with multiplications by 8.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I wonder if we also shouldn't do
if (safe_scale_64bit (..., &tmp)) tmp = max_count;
in the existing as well as new sp
Hi!
This testcase was made latent by r14-4089 and got fixed both
on the trunk and 13 branch with PR113372 fix.
Adding testcase to the testsuite and will close the PR as a dup.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2024-03-28 Jakub Jelinek
Hi!
I've noticed a typo in a comment.
Fixed thusly, committed to trunk as obvious.
2024-03-28 Jakub Jelinek
* predict.cc (estimate_bb_frequencies): Fix comment typo,
scalling -> scaling.
--- gcc/predict.cc.jj 2024-01-18 08:44:33.593917768 +0100
+++ gcc/pr
On Thu, Mar 28, 2024 at 03:00:46PM +, Richard Sandiford wrote:
> > * gcc.target/aarch64/bitint-alignments.c: New test.
> > * gcc.target/aarch64/bitint-args.c: New test.
> > * gcc.target/aarch64/bitint-sizes.c: New test.
> > * gcc.target/aarch64/bitfield-bitint-abi.h: New header.
On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
> While the first Makefile.tpl hunk looks obviously ok, the others look
> completely wrong to me.
> There is nothing special about libgo vs. libbacktrace/libatomic
> compared to any other target library which is not boo
of the
similar license have the wording right.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-02 Jakub Jelinek
* Makefile.tpl: Fix duplicated words; returns returns ->
returns.
config/
* lcmessage.m4: Fix duplicated words; can can
On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote:
> The old code for the unused hidden parameter (which was the 9th param)
> would
> fall thru to the "return NULL_RTX;" which would make the callee assume
> there
> was a parameter save area allocated. Now instead
On Tue, Apr 02, 2024 at 02:06:27PM +0200, Richard Biener wrote:
> On Tue, 2 Apr 2024, Richard Biener wrote:
>
> > The following reduces peak memory use for the PR114480 testcase at -O1
> > which is almost exclusively spent by the ehcleanup pass in allocating
> > PHI nodes. The free_phinodes cache
least should mention it in Annex C
(though, where when it is a DR?).
2024-04-02 Jakub Jelinek
PR c++/114462
* cp-gimplify.cc (cp_fold): Implement C++26 P2809R3 - Trivial infinite
loops are not Undefined Behavior. For trivially empty WHILE_STMT,
DO_STMT or FOR_S
NT_REFs or MEM_REFs from the .rodata vars.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-02 Jakub Jelinek
PR middle-end/114552
* expr.cc (emit_push_insn): Only use store_constructor for
immediate_const_ctor_p if int_expr_size ma
On Wed, Apr 03, 2024 at 09:35:07AM +0200, Richard Biener wrote:
> Just in case making the control expression constant to the middle-end
> doesn't scale.
I think we need to evaluate it as constant expression in any case, that is
the only way to determine if it is trivial infinite loop or not.
The c
", str);
/* Prints: +1.41421356237309504880e+00 */
}
free (str);
}
printf ("%+-#*.20Qe\n", width, r);
printf ("%Qa\n", r);
printf ("%+-#46.*Qe\n", prec, r);
printf ("%d %Qe %d %Qe %d %Qe\n", 1, r, 2, r, 3, r);
return 0;
}
On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> > I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> > that just some
> > invalid code doesn't pass. By removing them you basically always create an
> > invalid case, this time in the other direction, valid calle
On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
> on 2024/4/3 16:35, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> >>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> >>> that jus
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:
> @@ -3954,8 +3956,8 @@ on the GPU.
> To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured
> with
> @option{--with-arch=@code{fiji}} or
> @option{--with-multilib-list=@code{fiji},...}. Note that support for Fi
Hi!
I'd like to ping the following patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html
PR114409 (part of a P1)
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648381.html
PR114426 P1
Thanks.
On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
> Thanks for the details on debugging support, but IIUC with this workaround
> being adopted, the debuggability on hidden args are already broken, aren't?
No.
In the correct program case, which should be the usual case, the caller will
pas
On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
> Using std::is_constant_evaluated directly in a loop condition is, as the
> paper says, unlikely and "horrendous code", so I'm not concerned about
> surprising effects, though I guess we should check for it with
> maybe_warn_for_consta
On Wed, Apr 03, 2024 at 12:58:12PM -0400, Jason Merrill wrote:
> On 4/3/24 12:42, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote:
> > > Using std::is_constant_evaluated directly in a loop condition is, as the
> > > paper says, un
).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-04 Jakub Jelinek
PR tree-optimization/114555
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): For
m_bitfld_load and save_cast_conditional add any needed PHIs
and adjust t4
could STRIP_ANY_LOCATION_WRAPPER as well, but as all we are looking for
is INTEGER_CST inside, just looking through NON_LVALUE_EXPR seems easier.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-04 Jakub Jelinek
PR c++/114537
* fold-con
they are 128-bit
and use only %xmm0-15 registers, assembler would again emit VEX encoded insn
which needs AES & AVX CPUID, rather than the EVEX encoded ones which need
VAES & AVX512VL CPUIDs.
Still, I wonder if -mvaes shouldn't imply at least -mavx512f and
-mno-avx512f shouldn't
On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
> On 4/4/24 13:38, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
> >
> >
> > libsanitizer/ChangeLog:
> >
> > * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> >
On Thu, Apr 04, 2024 at 07:28:40AM -0700, Palmer Dabbelt wrote:
> I'm not sure if we need release maintainer approval,
For cherry-picking one's own non-risky bugfixes for regression or
documentation bugs from trunk to release branches no special approval
is needed, or maintainer of the correspondi
expecting that.
The following patch fixes that.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk so
far.
2024-04-05 Jakub Jelinek
PR c++/114572
* cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new
on build_call_a result if it
patch fixes it to call maybe_warn_for_constant_evaluated
always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather than
true if it is if constexpr with non-dependent condition etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-05 Jakub Jelinek
alse at runtime.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-05 Jakub Jelinek
PR c++/114462
gcc/
* tree-core.h (enum annot_expr_kind): Add
annot_expr_maybe_infinite_kind enumerator.
* gimplify.cc (gimple_b
ow g++.dg/modules/modules.exp,
gcc.target/s390/s390.exp or gcc.target/i386/i386.exp deal with that,
by pruning some tests based on glob patterns from the list.
Tested on x86_64-linux with make -j32 check-d, ok for trunk?
2024-04-05 Jakub Jelinek
* gdc.dg/dg.exp: Prune gcov*.d from the
ote, the testcase is latent on the trunk, but reproduces on the 13
branch.
Bootstrapped/regtested on x86_64-linux and i686-linux on the trunk,
plus tested with the testcase on 13 branch with -m32/-m64 without/with
the tree-vect-loop.cc patch (where it FAILed before and now PASSes).
Ok for trunk
n CI.
I've committed this to trunk as obvious.
2024-04-05 Jakub Jelinek
* configure: Regenerate.
--- libatomic/configure.jj 2024-04-05 09:19:48.593040783 +0200
+++ libatomic/configure 2024-04-05 12:13:08.315682702 +0200
@@ -11456,7 +11456,7 @@ else
lt_dlunknown=0;
On Fri, Apr 05, 2024 at 02:22:18PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> -Whardened warns when -fhardened couldn't enable a hardening option
> because that option was disabled on the command line, e.g.:
>
> $ ./cc1plus -quiet g.C
On Fri, Apr 05, 2024 at 03:46:30PM -0600, Jeff Law wrote:
>
>
> On 4/5/24 3:27 PM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
> > > The following avoids re-walking and re-combining the instructions
> > > between i2 and i3 when the pa
on s390x-linux, ok for trunk?
2024-04-06 Jakub Jelinek
PR target/114605
* config/s390/s390.cc (s390_const_int_pool_entry_p): Punt
if mem doesn't have MODE_INT mode, or pool constant doesn't
have MODE_INT mode, or if pool constant mode is smaller than
On Mon, Apr 08, 2024 at 12:33:39PM +, Jiang, Haochen wrote:
> Sorry for the late response since I am on vacation for now.
>
> > As the following testcase shows, the above change was incorrect.
> >
> > Using aes isa for the second alternative is obviously wrong, aes is enabled
> > whenever -ma
tted the attached
patch to add the ChangeLog entries there by hand.
2024-04-08 Jakub Jelinek
* gcc-changelog/git_update_version.py: Add
8057f9aa1f7e70490064de796d7a8d42d446caf8 to IGNORED_COMMITS.
--- contrib/gcc-changelog/git_update_version.py.jj 2024-01-05
15:22:21.7
On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > PR middle-end/114604
> > * gimple-range.cc (enable_ranger): Initialize the global
> > bitmap obstack.
> > (disable_ranger): Release it.
> > ---
> > gcc/gimple-range.cc | 4
> > 1 file changed,
urns larger values than the argument and for
> 1.0 smaller values than the argument.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2024-04-09 Jakub Jelinek
PR libquadmath/114623
* sfp-machine.h: New file.
* math/sqrtq.c: Include from lib
86_64-linux and i686-linux, ok for trunk?
2024-04-09 Jakub Jelinek
PR middle-end/114628
* gimple-lower-bitint.cc (gimple_lower_bitint): Keep debug stmts
before returns_twice calls as is, don't push them into arg_stmts
vector/move to edges.
* gcc.dg/bi
On Tue, Apr 09, 2024 at 09:03:59AM +0200, Richard Biener wrote:
> > With the possibility of sounding like a broken record, I think
> > __builtin_unreachable is fundamentally flawed. It generates no code
> > and just lets the program continue if ever "reached". This is a
> > security risk and (IM
Hi!
Another patch from eyeballing
git grep -v 'long long\|optab optab\|template template\|double double' | grep '
\([a-zA-Z]\+\) \1 '
output, this time in gcc/ subdirectory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-09 Jakub Jelinek
gc
On Tue, Apr 09, 2024 at 09:44:01AM +0200, Richard Biener wrote:
> (why not do it at each such switch?)
Because the traps would then be added even to the bbs which later
end up in the middle of the function.
Jakub
On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote:
> Hello,
>
> On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
> > The rust frontend requires cargo to build some of it's components,
> > it's presence was not checked during configuration.
>
> I
Hi!
My earlier libquadmath change apparently broke mingw32 build, while on Linux
is included and defines these, on Mingw apparently that isn't
the case, while soft-fp wants a guarantee that sfp-machine.h defines these.
Tested on x86_64-linux, committed to trunk.
2024-04-09 Jakub Je
t something like
> * return TARGET_AES || mode != V16QImode ? \"vaesenc\t{%2, %1,
> %0|%0, %1, %2}"\" : \"%{evex%} vaesenc\t{%2, %1, %0|%0, %1, %2}\";
For a single alternative, it would need to be
{
return x86_evex_reg_mentioned_p (operands, 3)
? \&
ted() always
evaluates false in non-constexpr functions even when it will actually
evaluate to true if it will be trivial infinite loop.
Because of the earlier changes I've changed the
|| (!processing_template_decl && !trivial_infinite)
condition just to
|| !processing_template_decl
b
On Tue, Apr 09, 2024 at 02:49:09PM +0200, Richard Biener wrote:
> The following adjusts -flto option processing in lto-wrapper to have
> link-time -flto override any compile time setting.
>
> LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK for trunk and branches? GCC 11
Hi!
On Wed, Apr 03, 2024 at 11:48:20AM +0200, Jakub Jelinek wrote:
> I'd like to ping the following patches:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
> PR111284 P2
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html
&
avoid testing too many variants...
2024-04-10 Jakub Jelinek
PR c++/114409
* pt.cc (tsubst_expr) : Use tsubst_stmt rather
than tsubst_expr aka RECUR on op1.
* g++.dg/ext/pr114409-2.C: New test.
--- gcc/cp/pt.cc.jj 2024-04-09 09:29:04.721521726 +0200
+++ g
On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
> The following fixes a mismatch in COMPOUND_EXPR handling in
> tsubst_expr vs tsubst_stmt where the latter allows a stmt in
> operand zero but the former doesn't. This makes a difference
> for the case at hand because when the COMPOU
On Wed, Apr 10, 2024 at 07:10:52PM +0200, Richard Biener wrote:
> Ah, I saw the bugzilla patches and wanted this version to be sent
> because I think the COMPOUND_EXPR inconsistency is odd. So Jason,
> please still have a look, not necessarily because of the bug
> which can be fixed in multiple wa
On Fri, Apr 05, 2024 at 02:37:08PM -0400, Marek Polacek wrote:
> > This function is passed explicit opts and opts_set arguments, so it
> > shouldn't be using flag_something macros nor OPTION_SET_P, as the former
> > use global_options.x_flag_something rather than opts->x_flag_something
> > and the
ng patch fixes that. Unlike the previous case where
we knew that asan_frame_size + base_align_bias falls into the same bucket
as asan_frame_size, this isn't in some cases true anymore, so the patch
recomputes which bucket to use and if going to bucket 11 (because there is
no __asan_stack_mal
it doesn't.
Tested on x86_64, ok for trunk?
2024-04-11 Jakub Jelinek
* doc/invoke.texi (lujiazui): Clarify that while the CPUs do support
AVX and F16C, -march=lujiazui actually doesn't enable those.
--- gcc/doc/invoke.texi.jj 2024-04-11 09:26:01.156865894 +0200
+++
en added 2
further ones very soon afterwards, quite a long time before 13.2 release
and haven't regenerated. The patch applies cleanly to trunk as well.
Ok for trunk/13 branch?
2024-04-11 Jakub Jelinek
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
*
On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> I think we also want the same change for i386.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * config/abi/post/i386-linux-gnu/baseline_symbols.txt:
> Regenerate.
Not sure about that, the file is missing all the 3.4.30
On Thu, Apr 11, 2024 at 03:16:02PM +0100, Jonathan Wakely wrote:
> > That symbol should not be in this symver, see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
>
> Jakub's patch is just adding the symbols from gcc-
/2024-April/058570.html
patch; plus again hand edits for arches I don't have libraries for).
Ok for trunk after the PR114692 patch is committed?
2024-04-11 Jakub Jelinek
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-li
On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3
Hi!
When we are already touching this topic, here is a patch like r13-5126
which documents the upcoming release symbol versions in the documentation.
Ok for trunk?
2024-04-11 Jakub Jelinek
* doc/xml/manual/abi.xml: Add latest library versions.
* doc/html/manual/abi.html
On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote:
> > > + case RID_RETURN:
> > > + {
> > > + bool musttail_p = false;
> > > + std_attrs = process_stmt_hotness_attribute (std_attrs, attrs_loc);
> > > + if (lookup_attribute ("", "musttail", std_attrs))
> > > + {
> > > +
On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote:
> On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote:
> > * config/aarch64/heap-trampoline.c: Rename
> > __builtin_nested_func_ptr_created to __gcc_nested_func_ptr_created and
> > __builtin_ne
On Wed, Jan 31, 2024 at 12:59:27PM +0100, Jakub Jelinek wrote:
> On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote:
> > --- a/libgcc/config/aarch64/t-heap-trampoline
> > +++ b/libgcc/config/aarch64/t-heap-trampoline
> > @@ -16,4 +16,5 @@
> > # along with GCC;
On Wed, Jan 31, 2024 at 07:58:50PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 31, 2024 at 07:11:20PM +0100, Jakub Jelinek wrote:
> > On Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote:
> > > GNU binutils has no issues with it:
> >
> > I know, I meant gcc.
> &
On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> Attached patch OK? Copied inline for review convenience.
No, I think e.g. AIX doesn't support the z modifier.
I don't see %zd or %zu used anywhere except in gcc/jit/ which presumably
doesn't work on AIX.
If you really want to avoid
On Thu, Feb 01, 2024 at 02:01:17PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> > Attached patch OK? Copied inline for review convenience.
>
> No, I think e.g. AIX doesn't support the z modifier.
> I don't see %zd or
701 - 800 of 19085 matches
Mail list logo
