Hi!
When writing the PR98737 fix, I've handled just the case where people
use __atomic_op_fetch (p, x, y) etc.
But some people actually use the other builtins, like
__atomic_fetch_op (p, x, y) op x.
The following patch canonicalizes the latter to the former and vice versa
when possible if the resu
Hi!
The following patch avoids emitting a parameter copy statement when inlining
if the parameter has empty type. E.g. the gimplifier does something similar
(except that it needs to evaluate side-effects if any, which isn't the case
here):
/* For empty types only gimplify the left hand side and
Hi!
The changes done to genericize_if_stmt in order to improve
-Wunreachable-code* warning (which Richi didn't actually commit
for GCC 12) are I think fine for normal ifs, but for constexpr if
and consteval if we have two competing warnings.
The problem is that we replace the non-taken clause (the
On 1/12/22 14:34, Tomas Kalibera wrote:
On 1/11/22 2:37 PM, Martin Liška wrote:
Hello.
I do support the patch, but I would ...
Thanks, Martin, that makes the patch simpler and easier to maintain. Would the
attached version do?
Thanks
Tomas
On 1/7/22 19:33, Tomas Kalibera wrote:
+
Hi!
On 2020-11-13T23:22:30+0100, I wrote:
> I've pushed to master branch [...] commit
> e898ce7997733c29dcab9c3c62ca102c7f9fa6eb "Decompose OpenACC 'kernels'
> constructs into parts, a sequence of compute constructs", see attached.
>
> On 2019-02-01T00:59:30+0100, I wrote:
>> There's more work to
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all modes for epilogues', skipped
modes that should not be skipped since it used the vector mode provided
by autovectorize_vector_modes to derive the minimum VF required for it.
However, those modes s
On Thu, 13 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> The following patch avoids emitting a parameter copy statement when inlining
> if the parameter has empty type. E.g. the gimplifier does something similar
> (except that it needs to evaluate side-effects if any, which isn't the case
> here):
>
Hi!
On 2019-05-08T14:51:57+0100, Julian Brown wrote:
> - The "addressable" bit is set during the kernels conversion pass for
>variables that have "create" (alloc) clauses created for them in the
>synthesised outer data region (instead of in the front-end, etc.,
>where it can't be don
Hi!
On 2019-08-13T14:37:13-0700, Julian Brown wrote:
> This patch provides a workaround for unreliable operation of asynchronous
> kernels regions on AMD GCN. At present, kernels regions are decomposed
> into a series of parallel regions surrounded by a data region capturing
> the data-movement c
On Thu, Jan 13, 2022 at 10:54:15AM +0100, Richard Biener wrote:
> > The following patch avoids emitting a parameter copy statement when inlining
> > if the parameter has empty type. E.g. the gimplifier does something similar
> > (except that it needs to evaluate side-effects if any, which isn't th
Hi!
Jakub, I'd still like your comment on the two "should we" questions cited
below.
On 2021-08-24T13:43:38+0200, Richard Biener via Gcc-patches
wrote:
> On Tue, Aug 24, 2021 at 12:23 PM Thomas Schwinge
> wrote:
>> On 2021-08-19T22:13:56+0200, I wrote:
>> > On 2021-08-16T10:21:04+0200, Jakub
Hi,
On Tue, Jan 11 2022, Martin Liška wrote:
> Hello.
>
> I've got a patch series that does the renaming. It contains of 2 automatic
> scripts ([1] and [2]) that were run as:
>
> $ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.'
> && rename-gcc.py . -vv && git commit -
Pushed to master.
It's very unlikely that somebody is going to backport a revision
that is > 14 months old to a release branch.
contrib/ChangeLog:
* git-backport.py: Simplify the script as pre-auto-ChangeLog era
is 14 months old.
---
contrib/git-backport.py | 39 ++-
Hi!
This has fallen out of (unfinished...) work earlier in the year: pushed
to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
"Document current '-Wuninitialized'/'-Wmaybe-uninitialized' diagnostics
for OpenACC test cases".
Grüße
Thomas
-
Siemens Electronic Desig
Hi!
On 2022-01-13T11:55:03+0100, I wrote:
> This has fallen out of (unfinished...) work earlier in the year: pushed
> to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
> "Document current '-Wuninitialized'/'-Wmaybe-uninitialized' diagnostics
> for OpenACC test cases".
..., and comm
On 1/13/22 11:47, Martin Jambor wrote:
Hi,
On Tue, Jan 11 2022, Martin Liška wrote:
Hello.
I've got a patch series that does the renaming. It contains of 2 automatic
scripts ([1] and [2]) that were run as:
$ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' &&
renam
On 1/13/22 10:40 AM, Martin Liška wrote:
[...]
Apart from that, I support the patch (I cannot approve it). Note we're
now approaching
stage4 and this is definitelly a stage1 material (opens after GCC
12.1.0 gets released).
Thanks, Martin, I've updated the patch following your suggestions.
Ch
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
Updated patch: this version fixes some missed cases of malloc in the
realloc implementation. It also reworks the unused variable workarounds
so that the work better with my reworked pinned memory patches I've not
posted yet.
Andrewlibgomp, nvptx: low-latency memory allocator
This patch adds s
On Thu, Jan 13, 2022 at 11:59 AM Martin Liška wrote:
>
> On 1/13/22 11:47, Martin Jambor wrote:
> > Hi,
> >
> > On Tue, Jan 11 2022, Martin Liška wrote:
> >> Hello.
> >>
> >> I've got a patch series that does the renaming. It contains of 2 automatic
> >> scripts ([1] and [2]) that were run as:
> >
On 1/13/22 12:14, Richard Biener wrote:
But please make sure all intermediate revs will still build.
That's not possible :) I don't it's a good idea mixing .cc renaming
and changes in that files.
Martin
On 2022-01-03 22:30, Richard Biener wrote:
On Wed, 22 Dec 2021, Jiufu Guo wrote:
Hi,
Normaly, estimate_numbers_of_iterations get/caculate niter first,
and then invokes infer_loop_bounds_from_undefined. While in some case,
after a few call stacks, estimate_numbers_of_iterations is invoked
befo
On Thu, Jan 13, 2022 at 12:20:57PM +0100, Martin Liška wrote:
> On 1/13/22 12:14, Richard Biener wrote:
> > But please make sure all intermediate revs will still build.
>
> That's not possible :) I don't it's a good idea mixing .cc renaming
> and changes in that files.
I think it is possible, but
Le 12/01/2022 à 21:29, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch improves error recovery after an invalid
structure constructor has been detected in a DATA statement.
Testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This should be a rathe
Hi!
On 2021-11-22T16:02:31+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Mon, Nov 22, 2021 at 03:49:42PM +0100, Thomas Schwinge wrote:
>> Then, regarding the user-visible behavior:
>>
>> > +#pragma acc routine /* { dg-error "not immediately followed by a single
>> > function declaration or d
On Thu, Jan 13 2022, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jan 13, 2022 at 12:20:57PM +0100, Martin Liška wrote:
>> On 1/13/22 12:14, Richard Biener wrote:
>> > But please make sure all intermediate revs will still build.
>>
>> That's not possible :) I don't it's a good idea mixing .cc re
Hi!
On 2022-01-04T15:12:58+0100, Tobias Burnus wrote:
> This commit r12-6209 now makes the testcases iterate over all devices
> (including the initial/host device).
>
> Hence, with multiple non-host devices and this test, the error had been
> found before ... ;-)
Yay for test cases! :-)
... bu
on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote:
> on 2022/1/13 上午11:44, David Edelsohn wrote:
>> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:
>>>
>>> Hi David,
>>>
>>> on 2022/1/13 上午11:07, David Edelsohn wrote:
On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
>
> Hi,
>>>
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
> This time to the list too (sorry for double email)
>
> Hi,
>
> The original patch '[vect] Re-analyze all modes for epilogues', skipped modes
> that should not be skipped since it used the vector mode provided by
> autovectorize_vector_modes to d
Hi David,
on 2022/1/13 上午11:12, David Edelsohn wrote:
> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
>> GET_MODE_NUNITS, which can use known constant instead.
>
> I'll let Segher decide, but often the additional
On Tue, Jan 11, 2022 at 10:31:54PM +, Hafiz Abid Qadeer wrote:
> + gfc_omp_namelist *n;
> + for (n = *head; n; n = n->next)
Better
for (gfc_omp_namelist *n = *head; n; n = n->next)
as we are in C++ and n isn't used after the loop.
> + /* non-composite co
Martin Sebor via Gcc-patches writes:
> On 1/12/22 02:02, Martin Liška wrote:
>> Hello.
>>
>> We've got -Wformat-diag for some time and I think we should start using it
>> in -Werror for GCC bootstrap. The following patch removes last pieces of
>> the warning
>> for rs6000 target.
>>
>> Ready to
On Thu, 13 Jan 2022, guojiufu wrote:
> On 2022-01-03 22:30, Richard Biener wrote:
> > On Wed, 22 Dec 2021, Jiufu Guo wrote:
> >
> >> Hi,
> >>
> >> Normaly, estimate_numbers_of_iterations get/caculate niter first,
> >> and then invokes infer_loop_bounds_from_undefined. While in some case,
> >> af
On Thu, 13 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> When writing the PR98737 fix, I've handled just the case where people
> use __atomic_op_fetch (p, x, y) etc.
> But some people actually use the other builtins, like
> __atomic_fetch_op (p, x, y) op x.
> The following patch canonicalizes the latt
On 13/01/2022 12:36, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all modes for epilogues', skipped modes
that should not be skipped since it used the vector mode provided
On 05/01/2022 17:07, Andrew Stubbs wrote:
I don't believe 64KB will be anything like enough for any real HPC
application. Is it really worth optimizing for this case?
Anyway, I'm working on an implementation using mmap instead of malloc
for pinned allocations. I figure that will simplify the u
A quick addition to range ops for
LHS = OP1 >> OP2
if OP1 and OP2 are both >= 0, then we can register the relation LHS
<= OP1 and all the expected good things happen.
Bootstrapped on x86_64-pc-linux-gnu with no regressions.
OK for trunk?
Andrew
From c34dab537d6f54b66b430f5980cde278fa03
This patch actually addresses a few PRs.
The root PR was 97909. Ranger context functionality was added to
fold_const back in early November
(https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583216.html)
The other 2 PRs mentioned (83072 and 83073) partially worked after this,
but the
Variable indexing of a __builtin_shufflevector result is broken because
we fail to properly mark the TARGET_EXPR decl as addressable.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2022-01-13 Richard Biener
PR c/104002
gcc/c-family/
* c-common.c (c_
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
>
> On 13/01/2022 12:36, Richard Biener wrote:
> > On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
> >
> >> This time to the list too (sorry for double email)
> >>
> >> Hi,
> >>
> >> The original patch '[vect] Re-analyze all modes for epilogues',
On Thu, Jan 13, 2022 at 02:49:47PM +0100, Richard Biener wrote:
> > + tree d = build_debug_expr_decl (type);
> > + gdebug *g
> > + = gimple_build_debug_bind (d, build2 (rcode, type,
> > + new_lhs, arg),
> > +
On Thu, Jan 13, 2022 at 03:12:03PM +0100, Richard Biener wrote:
> Variable indexing of a __builtin_shufflevector result is broken because
> we fail to properly mark the TARGET_EXPR decl as addressable.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2022-0
This patch series add initial support for allocate directive in the
gfortran. Although every allocate directive is parsed, only those
which are associated with an allocate statement are translated. The
lowering consists of replacing implicitly generated malloc/free call
from the allocate statement
Currently we only make use of this directive when it is associated
with an allocate statement.
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_node): Handle EXEC_OMP_ALLOCATE.
(show_code_node): Likewise.
* gfortran.h (enum gfc_statement): Add ST_OMP_ALLOCATE.
gcc/fortran/ChangeLog:
* trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
(gfc_trans_omp_allocate): New function.
(gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
gcc/ChangeLog:
* tree-pretty-print.c (dump_omp_clause): Handle OMP_CLAUSE_ALLOC
Currently we are only handling omp allocate directive that is associated
with an allocate statement. This statement results in malloc and free calls.
The malloc calls are easy to get to as they are in the same block as allocate
directive. But the free calls come in a separate cleanup block. To h
gcc/ChangeLog:
* doc/gimple.texi: Describe GIMPLE_OMP_ALLOCATE.
* gimple-pretty-print.c (dump_gimple_omp_allocate): New function.
(pp_gimple_stmt_1): Call it.
* gimple.c (gimple_build_omp_allocate): New function.
* gimple.def (GIMPLE_OMP_ALLOCATE): New node.
This patch looks for malloc/free calls that were generated by allocate statement
that is associated with allocate directive and replaces them with GOMP_alloc
and GOMP_free.
gcc/ChangeLog:
* omp-low.c (scan_sharing_clauses): Handle OMP_CLAUSE_ALLOCATOR.
(scan_omp_allocate): New.
This is v3 of this patch series, fixing issues I discovered before
committing v2 (which had been approved).
Thanks a lot to Richard Sandiford for his help.
The changes v2 -> v3 are:
Patch 4: Fix arm_hard_regno_nregs and CLASS_MAX_NREGS to support VPR.
Patch 7: Changes to the underlying repres
This patch mainly adds Neon tests similar to existing MVE ones,
to make sure we do not break Neon when fixing MVE.
mve-vcmp-f32-2.c is similar to mve-vcmp-f32.c but uses a conditional
with 2.0f and 3.0f constants to help scan-assembler-times.
2022-01-13 Christophe Lyon
gcc/testsuite/
These tests currently trigger an ICE which is fixed later in the patch
series.
The pr100757*.c testcases are derived from
gcc.c-torture/compile/20160205-1.c, forcing the use of MVE, and using
various types and return values different from 0 and 1 to avoid
commonalization with boolean masks. In ad
These tests are derived from the one provided in the PR: there is a
compile-only test because I did not have access to anything that could
execute MVE code until recently.
I have been able to add an executable test since QEMU supports MVE.
Instead of adding arm_v8_1m_mve_hw, I update arm_mve_hw so
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not seem to require this anymore, but it
seems to be a good thing to do
VPR_REG is the only register in its class, so it should be handled by
TARGET_CLASS_LIKELY_SPILLED_P, which is achieved by calling
default_class_likely_spilled_p. No test fails without this patch, but
it seems it should be implemented.
2022-01-13 Christophe Lyon
gcc/
* config/a
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
2022-01-13 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vmvnq_n_): Use V_elem mode
for operand 1.
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
ind
This patch implements support for vectors of booleans to support MVE
predicates, instead of HImode. Since the ABI mandates pred16_t (aka
uint16_t) to represent predicates in intrinsics prototypes, we
introduce a new "predicate" type qualifier so that we can map relevant
builtins HImode arguments a
We make use of qualifier_predicate to describe MVE builtins
prototypes, restricting to auto-vectorizable vcmp* and vpsel builtins,
as they are exercised by the tests added earlier in the series.
Special handling is needed for mve_vpselq because it has a v2di
variant, which has no natural VPR.P0 re
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type.
This patch fixes it by implementing TARGET_VECTORIZE_GET_MASK_MODE,
returning the appropriate VxBI mode
This is mostly a mechanical change, only tested by the intrinsics
expansion tests.
2022-01-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (BINOP_UNONE_NONE_NONE_QUALIFIERS):
Delete.
(TERNOP_UNONE_NONE_NONE_U
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
For v2di instructions, we keep the HI mode for predicates.
2022-01-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (STRSBS_P_QUALIF
This patch covers a few non-load/store builtins where we do not use
the iterator and thus we cannot use .
2022-01-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (CX_UNARY_UNONE_QUALIFIERS): Use
predicate.
(
VPR_REG should be part of ALL_REGS, this patch fixes this omission.
2022-01-13 Christophe Lyon
gcc/
* config/arm/arm.h (REG_CLASS_CONTENTS): Add VPR_REG to ALL_REGS.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 2416fb5ef64..ea9fb16b9b1 100644
--- a/gcc/config
When compiling gcc.target/arm/mve/intrinsics/mve_immediates_1_n.c with
-mthumb -mfloat-abi=hard -march=armv8.1-m.main+mve.fp+fp.dp, the compiler
crashes because:
error: insn does not satisfy its constraints:
(insn 28 14 17 2 (set (reg:V8HI 16 s0 [orig:249 u16 ] [249])
(mem/c:V8HI (pre_modify:SI
On Thu, 13 Jan 2022, Jakub Jelinek wrote:
> On Thu, Jan 13, 2022 at 02:49:47PM +0100, Richard Biener wrote:
> > > + tree d = build_debug_expr_decl (type);
> > > + gdebug *g
> > > + = gimple_build_debug_bind (d, build2 (rcode, type,
> > > +
On Thu, Jan 13, 2022 at 2:58 PM Andrew MacLeod via Gcc-patches
wrote:
>
> A quick addition to range ops for
>
> LHS = OP1 >> OP2
>
> if OP1 and OP2 are both >= 0, then we can register the relation LHS
> <= OP1 and all the expected good things happen.
>
> Bootstrapped on x86_64-pc-linux-gnu wi
On Thu, Jan 13, 2022 at 2:59 PM Andrew MacLeod via Gcc-patches
wrote:
>
> This patch actually addresses a few PRs.
>
> The root PR was 97909. Ranger context functionality was added to
> fold_const back in early November
> (https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583216.html)
>
>
On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote:
>
> Hi David,
>
> on 2022/1/13 上午11:12, David Edelsohn wrote:
> > On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
> >> GET_MODE_NUNITS, which can use known con
On 12/01/2022 12:59, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
for ARM target.
> diff --git a/gcc/config/arm/arm-builtins.c
b/gcc/config/arm
On 13/01/2022 14:25, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
On 13/01/2022 12:36, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all modes f
On Thu, Jan 13, 2022 at 03:37:31PM +, Richard Earnshaw via Gcc-patches
wrote:
> I'm not sure about this hunk. It changes a literal '<'...'>' into quotes.
> The text is trying to say you substitute with a digit in the range
> shown. Closer would be:
>
> "range [0-%d] enabled with %<+cd
On 1/13/22 16:37, Richard Earnshaw wrote:
"range [0-%d] enabled with %<+cdecp%>"
Great, this works.
So I'm going to push the commit.
Martin
The other changes look OK.
On 1/13/22 05:55, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
On 1/12/22 02:02, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
for rs60
For define_insn_and_split "*xor2andn":
1. Refine predicate of operands[0] from nonimmediate_operand to
register_operand.
2. Remove TARGET_AVX512BW from condition to avoid kmov when TARGET_BMI
is not available.
3. Force_reg operands[2].
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok
On 1/6/22 17:30, Martin Liška wrote:
I really welcome that, I've pushed devel/loop-unswitch-support-switches
branch with first changes you pointed out. Feel free playing with the branch.
Hello.
I've just pushed a revision to the branch that introduced top-level comment.
Feel free to play with
On 1/13/22 13:55, Richard Sandiford wrote:
Like you say in the linked message, we could add an explicit noun too.
But the change seems OK as-is to me.
May I consider it as an approval of the suggested patch?
Thanks,
Martin
On 1/13/22 03:55, Thomas Schwinge wrote:
Hi!
This has fallen out of (unfinished...) work earlier in the year: pushed
to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
"Document current '-Wuninitialized'/'-Wmaybe-uninitialized' diagnostics
for OpenACC test cases".
Thanks for the
2022-01-13 Uroš Bizjak
gcc/ChangeLog:
PR target/104003
* config/i386/mmx.md (*xop_pcmov_): Use VI_16_32 mode iterator.
gcc/testsuite/ChangeLog:
PR target/104003
* g++.target/i386/pr103861-1-sse4.C: New test.
* g++.target/i386/pr103861-1-xop.C: Ditto.
Bootstrapped and reg
On Thu, Jan 13, 2022 at 7:28 AM Kewen.Lin wrote:
>
> on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote:
> > on 2022/1/13 上午11:44, David Edelsohn wrote:
> >> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:
> >>>
> >>> Hi David,
> >>>
> >>> on 2022/1/13 上午11:07, David Edelsohn wrote:
> O
Hi!
I forgot to change the gfortran.map-sun goal to gfortran.ver-sun
when changing other spots for the preprocessed version file.
Fixed thusly, committed to trunk as obvious.
2022-01-13 Jakub Jelinek
PR libfortran/104006
* Makefile.am (gfortran.map-sun): Rename target to ...
On 1/13/22 10:13, Richard Biener wrote:
On Thu, Jan 13, 2022 at 2:59 PM Andrew MacLeod via Gcc-patches
wrote:
This patch actually addresses a few PRs.
The root PR was 97909. Ranger context functionality was added to
fold_const back in early November
(https://gcc.gnu.org/pipermail/gcc-patches
Changes since v8[8]:
- Refactored and expanded builtin-feclearexcept-feraiseexcept-2.c
testcase:
+ Use a macro to avoid extended repetition of the core test code.
+ Expanded the test code to check builtins return code.
+ Added more tests to test all valid (standard) exceptions inp
The cprop_hardreg pass is built around the assumption that accessing a
register in a narrower mode is the same as accessing the lowpart of
the register. This unfortunately is not true for vector registers on
IBM Z. This caused a miscompile of LLVM with GCC 8.5. The problem
could not be reproduced
On Thu, Jan 13, 2022 at 04:07:20PM +0100, Richard Biener wrote:
> I'm mostly concerned about the replace_uses_by use. forwprop
> will go over newly emitted stmts and thus the hypothetical added
>
> lhs2 = d;
>
> record the copy and schedule the stmt for removal, substituting 'd'
> in each us
Hi!
I'd like to ping this patch:
> 2022-01-06 Jakub Jelinek
>
> PR c++/89074
> * fold-const.c (address_compare): Punt on comparison of address of
> one object with address of end of another object if
> folding_initializer.
>
> * g++.dg/cpp1y/constexpr-89074-1.C:
2022-01-13 Uroš Bizjak
gcc/ChangeLog:
* config/i386/mmx.md (negv2qi): Disparage GPR alternative a bit.
Disable for TARGET_PARTIAL_REG_STALL unless optimizing for size.
(negv2qi splitters): Use lowpart_subreg instead of
gen_lowpart to create subreg.
(v2qi3): Disparage GPR al
Ping.
On 11/22/21 1:38 PM, Pat Haugen via Gcc-patches wrote:
> Updated version of the patch. Changes made from original are updated
> commentary to hopefully aid readability, no functional changes.
>
>
> Implement more two insn constants. rotate_and_mask_constant covers
> 64-bit constants that
On 1/12/22 10:33, David Malcolm wrote:
On Tue, 2022-01-11 at 23:36 -0500, Jason Merrill wrote:
On 1/10/22 16:36, David Malcolm via Gcc-patches wrote:
On Thu, 2022-01-06 at 09:08 -0500, David Malcolm wrote:
On Sat, 2021-11-13 at 15:37 -0500, David Malcolm wrote:
This patch adds a new __attribu
Add V2QImode shift operations and split them to synthesized
double HI/LO QImode operations with integer registers.
Also robustify arithmetic split patterns.
2022-01-13 Uroš Bizjak
gcc/ChangeLog:
PR target/103861
* config/i386/i386.md (*ashlqi_ext_2): New insn pattern.
(*qi_ext_2)
On 10/01/22 11:45 +, Jonathan Wakely wrote:
CC libstdc++ and Jakub.
On 08/01/22 23:22 -0700, Sandra Loosemore wrote:
I've checked in these tweaks for various testcases that fail on
nios2-elf without an explicit -fdelete-null-pointer-checks option. This
target is configured to build with th
Dear all,
there was a regression handling overloaded elemental intrinsics,
leading to an ICE on valid code. Reported by Urban Jost.
The logic for when we need to scalarize a call to an intrinsic
seems to have been broken during the 9-release. The attached
patch fixes the ICE and seems to work o
On 12/9/21 10:51, Jason Merrill wrote:
On 12/4/21 12:23, Anthony Sharp wrote:
Hi Jason,
Hope you are well. Apologies for not coming back sooner.
>I'd put it just above the definition of saved_token_sentinel in
parser.c.
Sounds good, done.
>Maybe cp_parser_require_end_of_template_paramete
On 1/13/22 04:39, Jakub Jelinek wrote:
Hi!
The changes done to genericize_if_stmt in order to improve
-Wunreachable-code* warning (which Richi didn't actually commit
for GCC 12) are I think fine for normal ifs, but for constexpr if
and consteval if we have two competing warnings.
The problem is
On 1/6/22 04:24, Jakub Jelinek wrote:
The following testcase used to be incorrectly accepted. The match.pd
optimization that uses address_compare punts on folding comparison
of start of one object and end of another one only when those addresses
are cast to integral types, when the comparison i
On Thu, Jan 13, 2022 at 04:09:22PM -0500, Jason Merrill wrote:
> > The changes done to genericize_if_stmt in order to improve
> > -Wunreachable-code* warning (which Richi didn't actually commit
> > for GCC 12) are I think fine for normal ifs, but for constexpr if
> > and consteval if we have two co
Hi Martin!
On 2022-01-13T09:06:16-0700, Martin Sebor wrote:
> On 1/13/22 03:55, Thomas Schwinge wrote:
>> This has fallen out of (unfinished...) work earlier in the year: pushed
>> to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
>> "Document current '-Wuninitialized'/'-Wmaybe-uni
Hello world,
with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT. The following
now works:
koenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
real(kind=16) :: x
character (len=30) :: conv
On 1/13/22 18:11, Andreas Krebbel via Gcc-patches wrote:
...
> @@ -5949,7 +5959,7 @@ register if floating point arithmetic is not being
> done. As long as the\n\
> floating registers are not in class @code{GENERAL_REGS}, they will not\n\
> be used unless some pattern's constraint asks for one."
When a sequence of diagnostic messages bounces back and forth repeatedly
between two includes, as with
#include
std::map m ("123", "456");
The output is quite a bit longer than necessary because we dump the include
path each time it changes. I'd think we could print the include path once
for
On Thu, 2022-01-13 at 17:08 -0500, Jason Merrill wrote:
> When a sequence of diagnostic messages bounces back and forth
> repeatedly
> between two includes, as with
>
> #include
> std::map m ("123", "456");
>
> The output is quite a bit longer than necessary because we dump the
> include
> pat
On 1/13/22 16:23, Jakub Jelinek wrote:
On Thu, Jan 13, 2022 at 04:09:22PM -0500, Jason Merrill wrote:
The changes done to genericize_if_stmt in order to improve
-Wunreachable-code* warning (which Richi didn't actually commit
for GCC 12) are I think fine for normal ifs, but for constexpr if
and c
1 - 100 of 116 matches
Mail list logo
