Hi,
As PR103623 shows, it's a regression failure due to new built-in
function framework, previously we guard __builtin_{un,}pack_{longdouble,
ibm128} built-in functions under hard float, so they are unavailable
with the given configuration. While with new bif infrastructure, it
becomes available
On Wed, Mar 02, 2022 at 03:54:29PM -0500, Michael Meissner wrote:
> Optimize signed DImode -> TImode on power10.
> On power10, GCC tries to optimize the signed conversion from DImode to
> TImode by using the vextsd2q instruction. However to generate this
> instruction, it would have to generate
The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
calls the mark_dfs_back_edges() function that initializes the bit (I
didn't know about it). As a result the bit is not set when expected,
which can cause false positives under the right conditions.
The attached patch adds a
On Wed, Mar 02, 2022 at 09:51:26AM +0100, Richard Biener wrote:
> On Tue, Mar 1, 2022 at 11:41 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add TARGET_FOLD_MEMCPY_MAX for the maximum number of bytes to fold memcpy.
> > The default is
> >
> > MOVE_MAX * MOVE_RATIO (optimize_function_for_size_p
Optimize signed DImode -> TImode on power10.
In comparison to the patch I submitted on February 25th, this patch changes the
comments based on feedback from Will Schmidt, and I added 2 test cases, to test
the conversion when the target registers are GPRs and when the target registers
are Altivec
On Tue, Mar 01, 2022 at 10:28:57PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > No. insn_cost is only for correct, existing instructions, not for
> > made-up nonsense. I created insn_cost precisely to get away from that
> > aspect of rtx_cost (and some other issues, like, it is
On 2/20/2022 9:51 AM, Roger Sayle wrote:
This patch implements the missed optimization enhancement PR 83907,
by handling memset with a constant byte value in tree-ssa's strlen
optimization pass. Effectively, this treats memset(dst,'x',3) as
it would memcpy(dst,"xxx",3).
This patch also
On 2/28/2022 5:54 AM, Richard Biener via Gcc-patches wrote:
On Mon, 28 Feb 2022, Tobias Burnus wrote:
Ping**3
On 23.02.22 09:42, Tobias Burnus wrote:
PING**2 for the ME review or at least comments to that patch,
which fixes a build issue/ICE with nvptx
Patch:
On 3/1/2022 12:47 AM, Richard Biener via Gcc-patches wrote:
On Tue, 1 Mar 2022, Jiufu Guo wrote:
Segher Boessenkool writes:
On Thu, Feb 24, 2022 at 09:50:28AM +0100, Richard Biener wrote:
On Thu, 24 Feb 2022, Jiufu Guo wrote:
And another thing as Segher pointed out, CSE is doing too
On 3/1/2022 8:44 AM, H.J. Lu via Gcc-patches wrote:
Limit PR 35513 tests to Linux since they fail on 32-bit Solaris/x86 with
Solaris linker.
PR testsuite/104725
* g++.target/i386/pr35513-1.C: Limit to Linux.
* g++.target/i386/pr35513-2.C: Likewise.
OK
jeff
On 3/1/2022 11:33 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
The r12-7287-g1b71bc7c8b18bd1b change improved the -Wdeprecated
warning for C++, but regressed it for C, in particular in
gcc.dg/deprecated.c testcase we now report a type that actually isn't
deprecated as deprecated instead of
On 3/2/2022 2:47 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html
PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least
anti_adjust_stack for alignment pad if needed
patch.
So the issue is the stack
In order to be able to perform CTAD for a dependently-scoped template
such as A::B in the testcase below, we need to permit a
typename-specifier to resolve to a template as per [dcl.type.simple]/2,
at least when it appears in a CTAD-enabled context.
This patch implements this using a new tsubst
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conversion,
T is the specified type, which shall be auto." which doesn't allow
type-constraint auto.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
Attributes deprecated and unavailable are largely the same, except
that the former produces a warning whereas the latter produces an error.
So is_late_template_attribute should treat them the same. Confirmed by
Iain that this divergence is not intentional:
On Wed, Mar 02, 2022 at 05:22:21PM +, Kwok Cheung Yeung wrote:
> I have updated the patch to catch array elements and structure components as
> additional checks, in addition to checking that the variable is a scalar.
>
> The check has been moved to the end of resolve_omp_clauses as it is
Hi,
This patch merges the D front-end implementation with upstream dmd
423f19b41, as well as the D runtime libraries with druntime 100a608c,
and phobos a1f8c4c07.
D Runtime changes:
- Fix stdc.stdio bindings to not depend on druntime (PR104729).
- Implement stdc.math for Solaris
Hello
I have updated the patch to catch array elements and structure
components as additional checks, in addition to checking that the
variable is a scalar.
The check has been moved to the end of resolve_omp_clauses as it is more
appropriate there. This gets rid of the additional
Hi all,
This patch creates the arm and aarch64 sections in the changes.html page for
GCC 12.
Some features are common to both backends, so we use a shared section for those
(like last year).
This list is not complete, but should work fine for a start. feel free to tell
me if you think
Various parts of the omp code checked whether the size of a decl
was an INTEGER_CST in order to determine whether the decl was
variable-sized or not. If it was variable-sized, it was expected
to have a DECL_VALUE_EXPR replacement, as for VLAs.
This patch uses poly_int_tree_p instead, so that
+// Common logic for version locks
+struct version_lock
+{
+ // The lock itself
+ uintptr_t version_lock;
+};
version_lock must not overflow, right? This means we need a wider
counter on 32-bit, too. glibc contains a 62-bit counter that it uses
for its own data structure.
an overflow
On 2022-03-02 07:25, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu, also tested on various riscv and arm
targets (with gcc-11). Ok to install?
Yes.
Thank you on working this, Alex.
for gcc/ChangeLog
* lra-constraints.cc (undo_optional_reloads): Recognize and
* Thomas Neumann:
> +#ifndef HIDE_EXPORTS
> +#pragma GCC visibility push(default)
> +#endif
All defined functions are static, right? Then this isn't necessary.
> +// Common logic for version locks
> +struct version_lock
> +{
> + // The lock itself
> + uintptr_t version_lock;
> +};
On 2022-03-02 03:58, Richard Biener wrote:
In this PR allocnos_conflict_p takes 90% of the compile-time via
the calls from update_conflict_hard_regno_costs. This is due to
the high number of conflicts recorded in the dense bitvector
representation. Fortunately we can take advantage of the
On Tue, Mar 01, 2022 at 05:46:20PM +0100, Thomas Schwinge wrote:
> OK to proceed in this way?
With a suitable ChangeLog entry and one nit fixed yes.
> --- gcc/omp-low.cc
> +++ gcc/omp-low.cc
> @@ -188,7 +188,7 @@ struct omp_context
> static splay_tree all_contexts;
> static int
On Wed, 2 Mar 2022, Tamar Christina wrote:
> Hi All,
>
> This adds a vect_float requirements to this tests to stop them from running on
> targets that don't support float vectorization.
>
> Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master? and GCC 11?
OK.
>
> I would
Hi All,
This adds a vect_float requirements to this tests to stop them from running on
targets that don't support float vectorization.
Regtested on aarch64-none-linux-gnu and no issues.
Ok for master? and GCC 11?
I would normally have committed this as trivial but since I need GCC 11
too I've
On Mar 1, 2022, Alexandre Oliva wrote:
> On Feb 23, 2022, Alexandre Oliva wrote:
>> On Feb 21, 2022, Richard Biener wrote:
Ok to revert commit r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
>>> OK. Please re-open the bug as appropriate.
>> Thanks. I've reopened it. Here's what
On Tue, 1 Mar 2022, Qing Zhao wrote:
> Hi,
>
> This is the 2nd version of the patch based on the discussion on the initial
> version.
>
> Compared to the previous version, the major changes in this version are:
>
> 1. Merged two patches into one;
> 2. Re-organize the code to emit both
Le 01/03/2022 à 23:18, Harald Anlauf via Fortran a écrit :
I do hope I got you right. The attached patch fixes your variant
as well as the original testcase, and regtests fine.
Just to be sure: is this what you were thinking of?
Indeed, that’s what I had in mind.
Nice, I didn’t expect that
On Wed, Mar 2, 2022 at 10:23 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As mentioned in the PR, different standards have different definition
> on what is an UB left shift. They all agree on out of bounds (including
> negative) shift count.
> The rules used by ubsan are:
> C99-C2x
On Tue, Mar 01, 2022 at 12:07:49PM -0700, Martin Sebor wrote:
> Thanks for the fix. It makes sense to me. Besides the test for
> the false positives I would suggest to add one to verify that using
> the first argument to a strstr() call is diagnosed if it's dangling
> (both as is, as well as
Hi!
On Mon, Feb 28, 2022 at 04:49:08PM -0500, Vladimir Makarov via Gcc-patches
wrote:
> PR rtl-optimization/104637
> * gcc.target/i386/pr104637.c: New.
This testcase FAILs everywhere for 3 reasons:
1) the testcase can't work on ia32, where sizeof (long double) == 12
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html
PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least
anti_adjust_stack for alignment pad if needed
patch.
Thanks
Jakub
Hi!
I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590276.html
PR102586 - reject __builtin_clear_padding on non-trivially-copyable types with
one exception
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590641.html
PR104568 - fix up constexpr evaluation
On Wed, 2 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> When debugging the PR104589 issue, I've run into a problem that
> goto_locus doesn't show up in the logs, so it wasn't clear if
> the bug hasn't been introduced far earlier just by divergence
> in goto_locus of some edge.
>
>
On Wed, 2 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> This is similar to PR104237 and similarly to that, no testcase included
> for the testsuite, as we don't have a framework to compile/link with
> -g -flto and -g0 -flto and compare -fdump-final-insns= results from
> the lto1 compilations.
>
>
Hi!
These testcases started failing with r12-630 and one of them
got fixed with r12-4531 (aka PR102764 fix and r12-4616 further
improved the fix) and the other went latent in r12-2591 (i.e. threader
changes) and I believe was fixed for real by the PR102764 fix too.
Regtested on x86_64-linux and
Hi!
When debugging the PR104589 issue, I've run into a problem that
goto_locus doesn't show up in the logs, so it wasn't clear if
the bug hasn't been introduced far earlier just by divergence
in goto_locus of some edge.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk,
or for
Hi!
This is similar to PR104237 and similarly to that, no testcase included
for the testsuite, as we don't have a framework to compile/link with
-g -flto and -g0 -flto and compare -fdump-final-insns= results from
the lto1 compilations.
With -flto, whether two location_t compare equal or not and
Hi!
This fixes some comment spelling bugs in tree-ssa-strlen.cc.
Committed as obvious.
2022-03-02 Jakub Jelinek
* tree-ssa-strlen.cc (strlen_pass::handle_assign,
strlen_pass::before_dom_children): Comment spelling fixes.
--- gcc/tree-ssa-strlen.cc.jj 2022-02-04
Hi!
This fixes some spelling mistakes in ipa-modref*.
Committed as obvious.
2022-03-02 Jakub Jelinek
* ipa-modref-tree.cc (modref_access_node::contains,
modref_access_node::closer_pair_p, modref_access_node::insert,
modref_access_node::insert_kill): Comment spelling
Hi!
As mentioned in the PR, different standards have different definition
on what is an UB left shift. They all agree on out of bounds (including
negative) shift count.
The rules used by ubsan are:
C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB
C++11-C++17 x < 0 || ((unsigned) x >>
In this PR allocnos_conflict_p takes 90% of the compile-time via
the calls from update_conflict_hard_regno_costs. This is due to
the high number of conflicts recorded in the dense bitvector
representation. Fortunately we can take advantage of the bitvector
representation here and turn the O(n)
On Tue, Mar 1, 2022 at 11:41 PM H.J. Lu via Gcc-patches
wrote:
>
> Add TARGET_FOLD_MEMCPY_MAX for the maximum number of bytes to fold memcpy.
> The default is
>
> MOVE_MAX * MOVE_RATIO (optimize_function_for_size_p (cfun))
>
> For x86, it is MOVE_MAX to restore the old behavior before
I know
45 matches
Mail list logo
