Hi,
Same like PR101168, this patch is need for s390 to
avoid peeking eof after vector keyword.
And similar test case is also ok for s390.
Is this ok for trunk?
Jeff (Jiufu Guo)
PR target/95782
gcc/ChangeLog:
* config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty identifie
From: Pan Li
In previous, we allowed the target(("arch=+v")) for a function with
rv64gc build. This patch would like to support more arch options as
below:
* zve32x
* zve32f
* zve64x
* zve64f
* zve64d
* zvfhmin
* zvfh
For example, we have sample code as below.
vfloat32m1_t
__attribute__((target
在 2024/3/26 下午5:48, Xi Ruoyao 写道:
The latency of LA464 and LA664 division instructions depends on the
input. When I updated the costs in r14-6642, I unintentionally set the
division costs to the best-case latency (when the first operand is 0).
Per a recent discussion [1] we should use "somethi
26 Mar 2024 10:36:45 pm Peter Damianov :
lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If there is no suitable "touch" or "mv" available, then this errors
with
"The system cannot find the file specified".
The solution her
lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If there is no suitable "touch" or "mv" available, then this errors with
"The system cannot find the file specified".
The solution here is to check if sh -c true works, before tryi
On Linux/x86_64,
fa60ac549649655a3f55e69f83d2e97423d3eb5c is the first bad commit
commit fa60ac549649655a3f55e69f83d2e97423d3eb5c
Author: Cupertino Miranda
Date: Tue Mar 26 11:59:47 2024 +
btf: Emit labels in DATASEC bts_offset entries.
caused
FAIL: gcc.dg/debug/btf/btf-datasec-1.c s
On Linux/x86_64,
c4f2c84e8fa369856aee76679590eb613724bfb0 is the first bad commit
commit c4f2c84e8fa369856aee76679590eb613724bfb0
Author: Jakub Jelinek
Date: Tue Mar 26 11:21:38 2024 +0100
fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51]
caused
FAIL: gcc.c-tor
Hi Jerry,
Am 26.03.24 um 04:18 schrieb Jerry D:
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
Vaseeharan Vinayagamoorthy writes:
> Hi Richard,
>
> I think this patch is breaking the build of aarch64-none-elf and
> aarch64-none-linux-gnu targets, when building with GCC 4.8.
> This is not an issue when building with GCC 7.5.
>
> Kind regards,
> Vasee
Thanks. I pushed the attached patch to
On Tue, 26 Mar 2024, Qing Zhao wrote:
> > What happens when there are multiple counted_by attributes on the same
> > field? As far as I can see, all but one end up being ignored (by the code
> > that actually uses the attribute).
>
> In general, is there any rule for handling multiple same att
As mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648397.html ,
do some additional cleanup of the macros and aliases:
Cleanup the macros to add the libat_ prefixes in atomic_16.S. Emit the
alias to __atomic_ when ifuncs are not enabled in the ENTRY macro.
Passes regress and
On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
wrote:
>
> Makefile.def contains already:
>
> host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84
> - "libbacktrace/: * Initial implementation" year 2012
>
> host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53d
Hello Ian,
Makefile.def contains already:
host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 -
"libbacktrace/: * Initial implementation" year 2012
host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 -
year 2004
Greetings
Дилян
Am 25. März
David Faust writes:
> On 3/26/24 07:28, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch is an expected fix for the issue reported by systemd in:
>> https://github.com/systemd/systemd/issues/31888
>> Also, Jose Marchesi opened the following bugzilla to report it:
>> https://gcc.gnu.org/
> On Mar 26, 2024, at 11:21, Joseph Myers wrote:
>
> On Tue, 26 Mar 2024, Qing Zhao wrote:
>
+@cindex @code{counted_by} variable attribute
+@item counted_by (@var{count})
+The @code{counted_by} attribute may be attached to the C99 flexible array
+member of a structure. It
On 3/26/24 07:28, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch is an expected fix for the issue reported by systemd in:
> https://github.com/systemd/systemd/issues/31888
> Also, Jose Marchesi opened the following bugzilla to report it:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114
Hi!
Apparently I've somehow screwed up the adjustments of the originally tested
testcase, tweaked it so that in the second/third cases it actually see
a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into,
and didn't update the expected value.
Tested on x86_64-linux -m32/-m64 with
On Tue, 26 Mar 2024, Qing Zhao wrote:
> >> +@cindex @code{counted_by} variable attribute
> >> +@item counted_by (@var{count})
> >> +The @code{counted_by} attribute may be attached to the C99 flexible array
> >> +member of a structure. It indicates that the number of the elements of
> >> the
> >>
Thanks, will update.
Qing
> On Mar 25, 2024, at 16:50, Joseph Myers wrote:
>
> On Wed, 20 Mar 2024, Qing Zhao wrote:
>
>> + the size of the element can be retrived from the result type of the call,
>> + which is the pointer to the array type. */
>
> Again, start a sentence with an upperc
> On Mar 25, 2024, at 16:48, Joseph Myers wrote:
>
> On Wed, 20 Mar 2024, Qing Zhao wrote:
>
>> + /* get the TYPE of the counted_by field. */
>
> Start comments with an uppercase letter.
Okay.
>
>> + The type of the first argument of this function is a POINTER type
>> + to the orig
Hi, Joseph,
Thanks a lot for the reviews.
> On Mar 25, 2024, at 16:44, Joseph Myers wrote:
>
> On Wed, 20 Mar 2024, Qing Zhao wrote:
>
>> + /* This attribute only applies to a C99 flexible array member type. */
>> + else if (! c_flexible_array_member_type_p (TREE_TYPE (decl)))
>> +{
>>
They were once mistakenly removed with
"xtensa: Remove old broken tweak for leaf function", but caused unwanted
register spills.
gcc/ChangeLog:
* config/xtensa/xtensa.h (LEAF_REGISTERS, LEAF_REG_REMAP):
Withdraw the removal.
(REG_ALLOC_ORDER): Cosmetics.
* config/x
No functional changes.
gcc/ChangeLog:
* config/xtensa/xtensa.cc
(gen_int_relational, gen_float_relational): Replace tempvar-based
value-swapping codes with std::swap.
* config/xtensa/xtensa.md (movdi_internal, movdf_internal):
Ditto.
---
gcc/config/xtensa/
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
We used to hit the "Error reporting routines re-entered." ICE here but
it was fixed by Patrick's r14-3809.
PR c++/100557
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100557.C: New test.
---
.../g++.dg/cpp2a/concepts-
Hi everyone,
This patch is an expected fix for the issue reported by systemd in:
https://github.com/systemd/systemd/issues/31888
Also, Jose Marchesi opened the following bugzilla to report it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431
Please notice that the function created was inspired
On Tue, 27 Feb 2024, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Patrick Palka wrote:
>
> > On Thu, 15 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > One would expect consecutive ca
On Tue, 5 Mar 2024, Patrick Palka wrote:
> On Tue, 27 Feb 2024, Patrick Palka wrote:
>
> > On Mon, 26 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
> > > look reasonable?
> > >
> > > -- >8 --
> > >
> > > One known missing piece i
On Mon, 11 Mar 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk and release branches?
Ping.
>
> -- >8 --
>
> r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
> first so that we prefer processing a local speciali
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
-- >8 --
gcc/testsuite/ChangeLog:
* g++.dg/modules/decltype-1_a.C: Add missing } to dg-module-do
directive.
* g++.dg/modules/lambda-5_a.C: Likewise.
---
gcc/testsuite/g++.dg/modules/decltype-1_a.C | 2 +-
gcc/
On Thu, 7 Mar 2024, Jason Merrill wrote:
> On 1/29/24 17:42, Patrick Palka wrote:
> > On Mon, 29 Jan 2024, Patrick Palka wrote:
> >
> > > On Fri, 26 Jan 2024, Jason Merrill wrote:
> > >
> > > > On 1/26/24 17:11, Jason Merrill wrote:
> > > > > On 1/26/24 16:52, Jason Merrill wrote:
> > > > > > On
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
I wonder if more generally we need to be doing more work when importing
definitions from header units especially to handle all the work that
'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have
been perfor
On Mär 15 2024, Victor Do Nascimento wrote:
> \ No newline at end of file
Please fix that.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Victor Do Nascimento writes:
> Given how, at present, the choice of using LSE128 atomic instructions
> by the toolchain is delegated to run-time selection in the form of
> Libatomic ifuncs, responsible for querying target support, the
> `+lse128' target architecture compile-time flag is absent fro
Hi Richard,
> This description is too brief for me. Could you say in detail how the
> new scheme works? E.g. the description doesn't explain:
>
> -if ARCH_AARCH64_HAVE_LSE128
> -AM_CPPFLAGS = -DHAVE_FEAT_LSE128
> -endif
That is not needed because we can include auto-config.h in atomic_16.
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> Thoughts? There are only a few uses for this presently, but I can see it
> being useful often in future. The library exposes which features it
> supports in a standardized way, so we can use those in tests to skip
> tests f
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can be replaced like
> t
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator: Fix _V badname.
OK for trunk, thanks.
> ---
> libstdc++-v3/include/std/generator | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/lib
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> Per the standard, the return type of a generators ranges iterator op*
> should be the reference type rather than the yielded type.
>
> The yielded type was used here by mistake.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator
Hi!
I've missed
FAIL: gcc.dg/torture/pr113126.c -O0 (test for excess errors)
etc. regressions on i686-linux since January. The problem is obvious
Excess errors:
.../gcc/testsuite/gcc.dg/torture/pr113126.c:11:1: warning: MMX vector return
without MMX enabled changes the ABI [-Wpsabi]
and I've
On Tue, 26 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> As I've tried to explain in the comments, the extract_muldiv_1
> MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
> If the multiplication is done in unsigned type or in signed
> type with -fwrapv, it is fairly obvious that max (a, b) *
On Tue, 2024-03-26 at 11:15 +0800, YunQiang Su wrote:
/* snip */
> With -ffinite-math-only -fno-signed-zeros, it does work with
> x >= y ? x : y
> while without `-ffinite-math-only -fno-signed-zeros`, it cannot.
> @Xi Ruoyao Is it expected by IEEE?
When y is (quiet) NaN and x is not, fmax(x,
The problem was is that in cp/pt.cc:find_template_parameter_info::found
compiler tried to get TEMPLATE_TEMPLATE_PARM tree from TEMPLATE_DECL tree by
DECL_INITIAL instead of TREE_TYPE(like for TYPE_DECL). Therefore, parm got
nullptr, because cp/pt.cc:process_template_parm doesn't assign anything
The following fixes too lax verification of vector type compatibility
in vectorizable_operation. When we only have a single vector size then
comparing the number of elements is enough but with SLP we mix those
and thus for operations like BIT_AND_EXPR we need to verify compatible
element types as
The problem was that in cp/pt.cc:find_template_parameter_info::found compiler
tried to get TEMPLATE_TEMPLATE_PARM tree from TEMPLATE_DECL tree by
DECL_INITIAL instead of TREE_TYPE(like for TYPE_DECL).Therefore, parm got
nullptr, because cp/pt.cc:process_template_parm doesn't assign anything to
Hi!
As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c)
The latency of LA464 and LA664 division instructions depends on the
input. When I updated the costs in r14-6642, I unintentionally set the
division costs to the best-case latency (when the first operand is 0).
Per a recent discussion [1] we should use "something sensible" instead
of it.
Use the a
The following adds missing verification of vector type compatibility
to recurrence vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible
On Tue, 26 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> Similar to the asan and ubsan changes, we shouldn't instrument non-generic
> address space accesses with tsan, because we just have library functions
> which take address of the objects as generic address space pointers, so they
> can't handle a
Hi!
The following testcase ICEs on arm, because it is the only
cdtor_returns_this target. Normally cp_fold never folds destructor
calls because the calls have VOID_TYPE_P return and maybe_constant_value
in that case does nothing, and cxx_eval_outermost_constant_expr does
something for those only
Hi!
Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.
Bootstrapped/regtested on x86_64-linux a
On Tue, Mar 26, 2024 at 9:43 AM Stefan Schulze Frielinghaus
wrote:
>
> This fixes the test on s390x. I'm also seeing test failures for
> riscv64-suse-linux-gnu, m68k-unknown-linux-gnu, pru-unknown-elf, and
> powerpc64le-unknown-linux-gnu. However, I didn't check them so this
> might or might not
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):
Fix co
The following fixes out-of-bounds read in the testcase.
Pushed to trunk and branch.
PR tree-optimization/114027
* gcc.dg/vect/pr114027.c: Fix iteration count.
---
gcc/testsuite/gcc.dg/vect/pr114027.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuit
This fixes the test on s390x. I'm also seeing test failures for
riscv64-suse-linux-gnu, m68k-unknown-linux-gnu, pru-unknown-elf, and
powerpc64le-unknown-linux-gnu. However, I didn't check them so this
might or might not fix those, too.
OK for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rte
55 matches
Mail list logo
