This makes the initializer for __table in __from_chars_alnum_to_val
dependent in an artificial way, which works around the modules testsuite
ICE reported in PR105297 by preventing the initializer from getting
evaluated at parse time.
Compared to the alternative workaround of using a non-local clas
This fires errors like
FAIL: g++.dg/opt/const7.C -std=c++14 scan-assembler-symbol-section symbol
b_var (found _ZL5b_var) has section ^\\.(const|rodata)|\\[RO\\] (found .srodata)
on RISC-V, where RO data can end up in the srodata section.
gcc/testsuite/ChangeLog:
* g++.dg/opt/cons
Hi Joshua:
> Does Asan work for RISC-V currently? It seems that '-fsanitize=address' is
> still unsupported for RISC-V. If I add '--enable-libsanitizer' in Makefile.in
> to reconfigure, there are compiling errors.
Is it because # libsanitizer not supported rv32, but it will break the
rv64 multi-
Arm 32, x86 (32) and mips has support for Asan[1], so we can
`reference` how they implement that,
but I guess the problem is we need someone to do that.
[1]
https://github.com/llvm/llvm-project/blob/main/compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake#L28
On Thu, Apr 21, 2022 at 7:54 AM Pal
On Thu, Apr 14, 2022 at 3:15 PM Ian Lance Taylor wrote:
>
> Thanks! I tested a version of that code with glibc, and it works
> there too, so I've committed this patch after testing on
> powerpc-linux-gnu and x86_64-linux-gnu. Please let me know about any
> problems.
Well, that patch broke PPC 3
On Tue, 19 Apr 2022 23:13:15 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Does Asan work for RISC-V currently? It seems that '-fsanitize=address' is
still unsupported for RISC-V. If I add '--enable-libsanitizer' in Makefile.in
to reconfigure, there are compiling errors.
Is it because # libsaniti
Here we issue a bogus error for the first assert in the test. Therein
we have
= (void) (VIEW_CONVERT_EXPR(yes) || handle_error ());,
VIEW_CONVERT_EXPR(value);
which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
. The problem here is that we call
7044 /* Check tha
On Tue, 2022-04-12 at 21:14 -0400, Michael Meissner wrote:
> Eliminate power8 fusion options, use power8 tuning, PR target/102059
>
> This is V4 of the patch. Compared to V3 of the patch, GCC will just
> ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
>
Hi,
No comments on code, a
Hi Fritz,
Am 20.04.22 um 20:03 schrieb Fritz Reese via Fortran:
See the bug report at gcc dot gnu dot org/bugzilla/show_bug.cgi?id=105310 .
This code was originally authored by me and the fix is trivial, so I
intend to commit the attached patch in the next few days if there is
no dissent.
OK
On 4/20/22 11:01 AM, Michael Meissner wrote:
> Ping patch.
>
> | Date: Tue, 12 Apr 2022 21:14:55 -0400
> | From: Michael Meissner
> | Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR
> target/102059
> | Message-ID:
>
> I feel this is an important patch. Please look
> Am 20.04.2022 um 18:52 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
> mark_jump_label on DEBUG_INSNs:
> if (NONDEBUG_INSN_P (insn))
>mark_jump_label (PATTERN (insn), insn, 0);
> and
> Am 20.04.2022 um 19:15 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> As mentioned in those PRs and I think in others too, there are some long
> time unresolved -fcompare-debug issues with DEBUG_BEGIN_STMTs in the FEs and
> during gimplification, especially with statement expression
This patch implements the constant folding optimization(s) described in
PR middle-end/98865, which should help address the serious performance
regression of Botan AES-128/XTS mentioned in PR tree-optimization/98856.
This combines aspects of both Jakub Jelinek's patch in comment #2 and
Andrew Pinsk
Doh! ENOPATCH.
> -Original Message-
> From: Roger Sayle
> Sent: 20 April 2022 18:50
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [x86 PATCH] Improved V1TI (and V2DI) mode equality/inequality.
>
>
> This patch (for when the compiler returns to stage 1) improves support for
> vector equal
See the bug report at gcc dot gnu dot org/bugzilla/show_bug.cgi?id=105310 .
This code was originally authored by me and the fix is trivial, so I
intend to commit the attached patch in the next few days if there is
no dissent.
The bug is caused by gfc_conv_union_initializer in
gcc/fortran/trans-e
This patch (for when the compiler returns to stage 1) improves support
for vector equality and inequality of V1TImode vectors, and V2DImode
vectors with sse2 but not sse4. Consider the three functions below:
typedef unsigned int uv4si __attribute__ ((__vector_size__ (16)));
typedef unsigned lon
Hi!
As mentioned in those PRs and I think in others too, there are some long
time unresolved -fcompare-debug issues with DEBUG_BEGIN_STMTs in the FEs and
during gimplification, especially with statement expressions, where we end
up with different code generation depending on whether there are
DEBU
Hi!
So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
for which that function is invoked need an extra artificial BIND_EXPR
around their body so that we move all variables of the bodies.
The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
or OMP_TAR
Hi!
When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
mark_jump_label on DEBUG_INSNs:
if (NONDEBUG_INSN_P (insn))
mark_jump_label (PATTERN (insn), insn, 0);
and so doesn't increment LABEL_NUSES from references in DEBUG_INSNs.
But, when we call emi
Em Wed, Apr 20, 2022 at 01:30:09PM +0200, Martin Liška escreveu:
> The change adds debuginfod to ./perf -vv:
>
> ...
> debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT
> ...
Thanks, applied.
- Arnaldo
> Signed-off-by: Martin Liska
> ---
> tools/perf/builtin-version.c | 1 +
> 1 file changed,
Ping patch.
| Date: Wed, 6 Apr 2022 14:21:26 -0400
| From: Michael Meissner
| Subject: [PATCH] Add zero_extendditi2. Improve lxvr*x code generation.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch. While this could be held for GCC 13, it would be nice to know
whether to keep this patch (which was asked for in one of the previous patches)
or discard it.
| Date: Fri, 1 Apr 2022 12:59:28 -0400
| From: Michael Meissner
| Subject: [PATCH] Replace UNSPEC with RTL code for extendditi2
Ping #2 on this patch.
| Date: Tue, 29 Mar 2022 23:25:31 -0400
| From: Michael Meissner
} Subject: [PATCH, V2] Optimize vec_splats of constant vec_extract for
V2DI/V2DF, PR target 99293.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ib
> On Apr 20, 2022, at 5:38 AM, Richard Biener
> wrote:
>
> On Tue, Apr 19, 2022 at 11:36 PM Qing Zhao wrote:
>>
>>
>>
>>> On Apr 14, 2022, at 1:53 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Apr 13, 2022 at 5:22 PM Qing Zhao wrote:
Hi, Richard,
Thanks a lot for
Ping patch.
| Date: Tue, 12 Apr 2022 21:14:55 -0400
| From: Michael Meissner
| Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR
target/102059
| Message-ID:
I feel this is an important patch. Please look at it and approve the patch or
give me feedback on how to chang
Hi!
This looks great :-)
On Wed, Apr 20, 2022 at 03:52:33PM +0200, Richard Biener wrote:
> The following mitigates a problem in combine distribute_notes which
> places an original REG_EH_REGION based on only may_trap_p which is
> good to test whether a non-call insn can possibly throw but not if
The following mitigates a problem in combine distribute_notes which
places an original REG_EH_REGION based on only may_trap_p which is
good to test whether a non-call insn can possibly throw but not if
actually it does or we care. That's something we decided at RTL
expansion time where we possibly
This patch adds enough support for "requires unified_address" to make
the sollve_vv testcases pass. It implements unified_address as a synonym
of unified_shared_memory, which is both valid and the only way I know of
to unify addresses with Cuda (could be wrong).
This patch should be applied on
For
omp parallel shared(array_desc_var)
the shared-variable is passed to the generated function as
argument - and replaced by a DECL_VALUE_EXPR inside the parallel region.
If inside the parallel region, a
omp target data has_device_addr(array_descr_var)
is used, the latter generates a
omp
Pushed to trunk now.
On Wed, 13 Apr 2022 at 15:24, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux, without libiconv installed, with libiconv installed,
> with libiconv installed but using an in-tree libiconv, with libiconv.a
> installed and using --with-libiconv-type=static, and wit
Tested x86_64-linux, pushed to trunk.
-- >8 --
The macro being tested here is wrong, but just happens to have the same
value as the one supposed to be tests.
libstdc++-v3/ChangeLog:
*
testsuite/21_strings/basic_string_view/operations/copy/char/constexpr.cc:
Check correct featur
> On Wed, Apr 20, 2022 at 01:47:43PM +0200, Martin Jambor wrote:
> > Hi,
> >
> > On Wed, Apr 20 2022, Jan Hubicka via Gcc-patches wrote:
> > >> On Wed, 20 Apr 2022, Jakub Jelinek wrote:
> >
> > [...]
> >
> > >> >
> > >> >if ((flag_openacc || flag_openmp)
> > >> >&& lookup_attribute
On Wed, Apr 20, 2022 at 01:47:43PM +0200, Martin Jambor wrote:
> Hi,
>
> On Wed, Apr 20 2022, Jan Hubicka via Gcc-patches wrote:
> >> On Wed, 20 Apr 2022, Jakub Jelinek wrote:
>
> [...]
>
> >> >
> >> >if ((flag_openacc || flag_openmp)
> >> >&& lookup_attribute ("omp declare target"
Hi,
On Wed, Apr 20 2022, Jan Hubicka via Gcc-patches wrote:
>> On Wed, 20 Apr 2022, Jakub Jelinek wrote:
[...]
>> >
>> >if ((flag_openacc || flag_openmp)
>> >&& lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
>> > --- gcc/cgraphclones.cc.jj 2022-01-18 11:58:58.9489
On 4/20/22 13:30, Martin Liška wrote:
The change adds debuginfod to ./perf -vv:
...
debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT
...
Signed-off-by: Martin Liska
---
tools/perf/builtin-version.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-version.c b/tools/perf/b
The change adds debuginfod to ./perf -vv:
...
debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT
...
Signed-off-by: Martin Liska
---
tools/perf/builtin-version.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-version.c b/tools/perf/builtin-version.c
index 9cd074a3d825..a71f
On Tue, Apr 19, 2022 at 11:36 PM Qing Zhao wrote:
>
>
>
> > On Apr 14, 2022, at 1:53 AM, Richard Biener
> > wrote:
> >
> > On Wed, Apr 13, 2022 at 5:22 PM Qing Zhao wrote:
> >>
> >> Hi, Richard,
> >>
> >> Thanks a lot for taking a look at this issue (and Sorry that I haven’t
> >> fixed this on
>
> The cgraph.cc change was what I actually needed for the fix, the
> cgraphclones.cc was only because I've noticed that it constructs a new
> node (so is initialized to whatever random flag_semantic_interposition is
> right now) and initializing it to what it is cloned from made more sense.
OK,
On Wed, Apr 20, 2022 at 11:06:12AM +0200, Jan Hubicka wrote:
> > On Wed, Apr 20, 2022 at 10:45:53AM +0200, Jan Hubicka wrote:
> > > So this change should be unnecessary unless there are nodes that are
> > > missing finalization stage. It also is not good enough since frontends
> > > may change opt
> On Wed, Apr 20, 2022 at 10:45:53AM +0200, Jan Hubicka wrote:
> > So this change should be unnecessary unless there are nodes that are
> > missing finalization stage. It also is not good enough since frontends
> > may change opt_for_fn between node creation and finalization of
> > compilation uni
On 4/20/22 10:55, Jan Hubicka via Gcc-patches wrote:
I tink we can just drop the sanity check completely. In general the
profile data may be corrupted and each use of it should be guarded to
not explode on such situation.
Makes sense to me. I'm going to do it once stage1 opens.
Cheers,
Martin
On Wed, Apr 20, 2022 at 10:45:53AM +0200, Jan Hubicka wrote:
> So this change should be unnecessary unless there are nodes that are
> missing finalization stage. It also is not good enough since frontends
> may change opt_for_fn between node creation and finalization of
> compilation unit (so even
> From: Sergei Trofimovich
>
> TOPN metrics are histograms that contain overall count and per-bucket
> count. Overall count can be nevative when two profiles merge and some
> of per-bucket metrics are dropped.
>
> Noticed as an ICE on python PGO build where gcc crashes as:
>
> during IPA pa
> The following makes sure that when we build the versioning condition
> for vectorization including the cost model check, we check for the
> cost model and branch over other versioning checks. That is what
> the cost modeling assumes, since the cost model check is the only
> one accounted for in
This simple patch avoids the ICE described in the PR:
internal compiler error: in simd_valid_immediate, at config/arm/arm.cc:12866
with an early exit from simd_valid_immediate if we are trying to
handle a vector of booleans and MVE is not enabled.
We still get an ICE when compiling the existing
g
> On Wed, 20 Apr 2022, Jakub Jelinek wrote:
>
> > Hi!
> >
> > cgraph_node has a semantic_interposition flag which should mirror
> > opt_for_fn (decl, flag_semantic_interposition). But it actually is
> > initialized not from that, but from flag_semantic_interposition in the
> > explicit symtab_
The following aligns ISEL VEC_COND_EXPR expansion using VCOND
with the optab query done by vector lowering. Instead of only
allowing the signed optab to provide EQ/NE compares we allow both
here though since there seems to be no documented canonicalization.
Bootstrap and regtest running on x86_64
On Tue, Apr 19, 2022 at 1:58 PM Roger Sayle wrote:
>
>
> This patch addresses PR middle-end/105135, a missed-optimization regression
> affecting mainline. I agree with Jakub's comment that the middle-end
> optimizations are sound, reducing basic blocks and conditional expressions
> at the tree-le
On Wed, 20 Apr 2022, Jakub Jelinek wrote:
> Hi!
>
> cgraph_node has a semantic_interposition flag which should mirror
> opt_for_fn (decl, flag_semantic_interposition). But it actually is
> initialized not from that, but from flag_semantic_interposition in the
> explicit symtab_node (symtab_typ
On Wed, Apr 20, 2022 at 4:19 AM Jason Merrill via Gcc-patches
wrote:
>
> On 4/18/22 10:03, Iain Sandoe wrote:
> > Whether it was intended or not, it is possible to define a coroutine promise
> > with multiple return_value() methods [which need not even have the same
> > type].
> >
> > We were not
50 matches
Mail list logo
