On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +for i, line in enumerate(lines):
>
On Thu, Jan 13, 2022 at 6:12 PM Andreas Krebbel via Gcc-patches
wrote:
>
> 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.
On Thu, Jan 13, 2022 at 5:01 PM Martin Liška wrote:
>
> 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
On Thu, 13 Jan 2022, Jakub Jelinek wrote:
> 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
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
>
> 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
> > No, the approach is wrong. You have to solve output clearing on RTL
> > level, please look at how e.g. tzcnt false dep is solved:
>
> Actually we have considered such approach before, but we found we need
> to break original define_insn to remove the mask/rounding subst,
> since define_split
On Fri, Jan 14, 2022 at 4:42 AM Palmer Dabbelt wrote:
>
> The code generated by -mcmodel=medany is defined to be
> position-independent, but is not guarnteed to function correctly when
> linked into position-independent executables or libraries. See the
> recent discussion at the psABI
> No, the approach is wrong. You have to solve output clearing on RTL
> level, please look at how e.g. tzcnt false dep is solved:
Actually we have considered such approach before, but we found we need
to break original define_insn to remove the mask/rounding subst,
since define_split could not
Richard Biener writes:
> 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,
>> >> ...
>> >>
>> >> Bootstrap and regtest pass on ppc64* and x86_64. Is this ok for trunk?
>> >
>> > So this is a
Here's the patch I'm going to check in, the patch is pre-approved in PR.
On Thu, Jan 13, 2022 at 11:59 PM liuhongt wrote:
>
> For define_insn_and_split "*xor2andn":
>
> 1. Refine predicate of operands[0] from nonimmediate_operand to
> register_operand.
> 2. Remove TARGET_AVX512BW from condition
On Fri, Jan 14, 2022 at 09:01:09AM +0530, Siddhesh Poyarekar wrote:
> Restrict negative offset computation only to dynamic object sizes, where
> size expressions are accurate and not a maximum/minimum estimate and in
> cases where negative offsets definitely mean an underflow, e.g. in
> MEM_REF of
The code generated by -mcmodel=medany is defined to be
position-independent, but is not guarnteed to function correctly when
linked into position-independent executables or libraries. See the
recent discussion at the psABI specification [1] for more details.
[1]:
Restrict negative offset computation only to dynamic object sizes, where
size expressions are accurate and not a maximum/minimum estimate and in
cases where negative offsets definitely mean an underflow, e.g. in
MEM_REF of the whole object with negative ofset in addr_object_size.
This ends up
On 1/13/22 12:56 PM, Harald Anlauf via Fortran wrote:
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
On Thu, 2022-01-13 at 14:08 -0500, Jason Merrill wrote:
> 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
Hi!
On Wed, Jan 12, 2022 at 10:02:36AM +0100, Martin Liška wrote:
> - error ("%qs requires ISA 3.0 IEEE 128-bit floating point", name);
> + error ("%qs requires ISA 3.0 IEEE 128-bit floating-point", name);
This change is incorrect. Floating point is not an adjective here.
It is
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
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
>
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 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
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
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
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
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
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 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
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
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
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.
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
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
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
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.
>
> *
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
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
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
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
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 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:
>
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
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
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/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
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/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
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 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
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
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
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
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 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
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,
> > > +
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
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
---
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.
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
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.
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
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
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
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
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/
*
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
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
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
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/
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
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.
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
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
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
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.
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
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.
>
>
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, 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',
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
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
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
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
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 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
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,
> >>
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
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
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 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
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,
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! :-)
...
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
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
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
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,
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
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 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:
>
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
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
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.
1 - 100 of 116 matches
Mail list logo
