> Am 05.02.2022 um 00:08 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The recent PR95115 change to punt in const_binop on folding operation
> with non-NaN operands into NaN if flag_trapping_math broke the following
> testcase, because the x * 0.0 simplification punts just if
> x
The PR92385 fix meant that we see more VEC_INIT_EXPR outside of INIT_EXPR;
in such cases, we need to wrap them in TARGET_EXPR. I previously fixed
that in build_array_copy; we also need it in process_init_constructor.
After fixing that, I needed to adjust a few places to recognize the
On Fri, Feb 4, 2022 at 3:21 AM Richard Sandiford via Gcc-patches
wrote:
>
> Sorry, just realised I'd never replied to this.
>
> Marc Poulhies writes:
> > Eric Botcazou writes:
> >>> The new variables seem to be unused, so I think slightly stronger
> >>> DCE could remove the calls even after the
On 5/2/22 01:22, Martin Liška wrote:
On 2/4/22 14:30, Jakub Jelinek via Gcc-patches wrote:
We don't ship any include-fixed headers in Fedora/RHEL.
Removing include-fixed from an installed folder, I see:
make[2]: Entering directory '/home/marxin/Programming/postgres/src/common'
gcc -Wall
On Fri, 4 Feb 2022 at 23:55, Jonathan Wakely wrote:
> +// Used to implement filesystem::remove_all.
> +fs::recursive_directory_iterator&
> +fs::recursive_directory_iterator::__erase(error_code* ecptr)
> +{
> + error_code ec;
> + if (!_M_dirs)
> +{
> + ec =
In the Go 1.18 release the predeclared identifier "any" is a new alias
for the type "interface{}". This patch adds this alias to the Go
frontend. This requires updating a test. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Tested x86_64-linux (and built on x86_64-w64-mingw), pushed to trunk.
The std::filesystem code needs to use posix::DIR not ::DIR, as that is
an alias for _WDIR on Windows.
libstdc++-v3/ChangeLog:
* src/filesystem/dir-common.h (_Dir_base::openat): Change return
type to use
On Fri, Feb 04, 2022 at 04:42:41PM -0500, Jason Merrill wrote:
> > @@ -20,9 +20,16 @@ along with GCC; see the file COPYING3.
> > #ifndef GCC_FOLD_CONST_H
> > #define GCC_FOLD_CONST_H
> > -/* Non-zero if we are folding constants inside an initializer; zero
> > - otherwise. */
> > +/* Nonzero
Tested powerpc64le-linux (and smoke tested with clang), pushed to trunk.
There is code that only expects to be compiled with clang++ and uses its
, which works because Clang supports the _Atomic specifier
in C++. The addition of to libstdc++ broke this code, as
now it finds the C++ header
Tested powerpc64le-linux, pushed to trunk.
LWG 3014 removed these incorrect noexcept specifications from the C++17
std::filesystem operations. They are also incorrect on the experimental
TS versions and should be removed from them too.
libstdc++-v3/ChangeLog:
*
We have recently updated the default for the `-misa-spec=' option, yet
we still have not documented it nor its `--with-isa-spec=' counterpart
in the GCC manuals. Fix that.
gcc/
* doc/install.texi (Configuration): Document `--with-isa-spec='
RISC-V option.
*
Tested powerpc64le-linux and powerpc-aix, pushed to trunk.
This fixes the remaining filesystem::remove_all race condition by using
POSIX openat to recurse into sub-directories and using POSIX unlinkat to
remove files. This avoids the remaining race where the directory being
removed is replaced
Hi!
The recent PR95115 change to punt in const_binop on folding operation
with non-NaN operands into NaN if flag_trapping_math broke the following
testcase, because the x * 0.0 simplification punts just if
x maybe a NaN (because NaN * 0.0 is NaN not 0.0) or if one of the operands
could be
On 2/4/22 17:10, Jakub Jelinek wrote:
On Fri, Feb 04, 2022 at 04:54:39PM -0500, Jason Merrill wrote:
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
Or shall it wait for GCC 13?
Hmm, I lean toward GCC 13; this seems more of a stage 3 change.
Ok.
I see you test valid uses of >=
On Fri, Feb 04, 2022 at 02:10:03PM -0600, Peter Bergner wrote:
> On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> > On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
> >> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> >>> If the user did not specify a default long double
On Fri, Feb 04, 2022 at 04:54:39PM -0500, Jason Merrill wrote:
> > Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
> > Or shall it wait for GCC 13?
>
> Hmm, I lean toward GCC 13; this seems more of a stage 3 change.
Ok.
> I see you test valid uses of >= in template arguments; you
On 2/4/22 12:04, Patrick Palka wrote:
On Thu, 3 Feb 2022, Jason Merrill wrote:
On 2/3/22 16:06, Patrick Palka wrote:
On Thu, 3 Feb 2022, Jason Merrill wrote:
On 2/3/22 14:58, Patrick Palka wrote:
When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be
On 2/4/22 09:12, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, for C++98 we have diagnostics that expect
terminating template arguments to be a mistake for > > (C++11
said it has to be treated that way), while if user trying to spare the
spacebar doesn't separate > from following = or >>
On 2/4/22 08:41, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:34:17PM -0500, Jason Merrill wrote:
On 2/3/22 16:18, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
I think it would be clearer to leave the !DECL_P case alone and add
/* In C++ it is
On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
>> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
>>> If the user did not specify a default long double format when configuring
>>> GCC, use the long double default from the
Hi!
PR100808 pointed out some trivial formatting issues with Power documentation
for basic ISA 3.1 built-in functions. This patch cleans those up.
Tested on powerpc64le-linux-gnu, committed as obvious.
Thanks!
Bill
2022-02-04 Bill Schmidt
gcc/
PR target/100808
*
On Fri, 04 Feb 2022 10:44:04 PST (-0800), ma...@embecosm.com wrote:
We have recently updated the default for the `-misa-spec=' option, yet
we still have not documented it nor its `--with-isa-spec=' counterpart
in the GCC manuals. Fix that.
gcc/
* doc/install.texi
We have recently updated the default for the `-misa-spec=' option, yet
we still have not documented it nor its `--with-isa-spec=' counterpart
in the GCC manuals. Fix that.
gcc/
* doc/install.texi (Configuration): Document `--with-isa-spec='
RISC-V option.
*
On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> > If the user did not specify a default long double format when configuring
> > GCC, use the long double default from the host compiler.
>
> That doesn't make any sense.
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 16:06, Patrick Palka wrote:
> > On Thu, 3 Feb 2022, Jason Merrill wrote:
> >
> > > On 2/3/22 14:58, Patrick Palka wrote:
> > > > When synthesizing a defaulted comparison op from
> > > > maybe_instantiate_noexcept, we seem to be forgetting to
On Fri, Feb 4, 2022 at 11:58 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase FAILs when configured with
> --with-long-double-format=ieee . Only happens in the -std=c* modes, not the
> GNU modes; while the glibc headers have __asm redirects of
> vsnprintf and __vsnprinf_chk to
Hi!
The following testcase FAILs when configured with
--with-long-double-format=ieee . Only happens in the -std=c* modes, not the
GNU modes; while the glibc headers have __asm redirects of
vsnprintf and __vsnprinf_chk to __vsnprintfieee128 and
__vsnprintf_chkieee128, the vsnprintf fortification
In recent versions of glibc fopen has __attribute__((malloc)).
Since we can not detect wether this attribute is present or not,
we avoid including stdio.h and instead forward declare what we
need in each test.
Signed-off-by: Joel Teichroeb
---
On 04.02.22 16:33, Thomas Schwinge wrote:
Maybe removed locally, I can't tell ;-) -- but it's still in the
commit that you pushed. See below.
Also, a commented-out '!$omp barrier'; not sure what that one is about.
I shall not do commits after one week of 6h+/day virtual OpenMP
Face2Face
On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> If the user did not specify a default long double format when configuring
> GCC, use the long double default from the host compiler.
That doesn't make any sense. The host compiler can be any random
compiler completely unrelated to the
Hi Tobias!
On 2022-02-04T14:57:07+0100, Tobias Burnus wrote:
> On 04.02.22 10:37, Thomas Schwinge wrote:
>>> I have attached a patch (not commited), which silences the three kind of
>>> warnings and fixes the interface issue.
>>> TODO: commit it.
>> Still "TODO: commit it" ;-) -- and while I
Use system default for long double unless it is overridden.
If the user did not specify a default long double format when configuring
GCC, use the long double default from the host compiler.
I tested this on the following systems. There were no regressions:
* Big endian Linux power8
Committed as obvious.
gcc/ChangeLog:
* doc/cpp.texi (Variadic Macros): Replace C++2a with C++20.
---
gcc/doc/cpp.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index d4290fefb41..90b2767e39a 100644
---
Tested powerpc64le-linux, pushed to trunk.
We should use the SUGGEST macro for std::uncaught_exception()
deprecation warnings.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h: Qualify std::allocator_traits in
deprecated warnings.
* libsupc++/exception
On 2/4/22 14:30, Jakub Jelinek via Gcc-patches wrote:
We don't ship any include-fixed headers in Fedora/RHEL.
Removing include-fixed from an installed folder, I see:
make[2]: Entering directory '/home/marxin/Programming/postgres/src/common'
gcc -Wall -Wmissing-prototypes -Wpointer-arith
On 2/4/22 14:07, Rainer Orth wrote:
Hi Martin,
It seems to me that fixincludes is hardy unused feature for nowadays header
files and so I'm suggesting a developer option that can skip the fixing.
please remember that there's a world beyond current-day Linux.
Sure! That's why I'm suggesting
On 2/4/22 14:30, Jakub Jelinek via Gcc-patches wrote:
On Fri, Feb 04, 2022 at 02:25:17PM +0100, Richard Biener via Gcc-patches wrote:
Besides, have you actually run a regtest with that option? I'm asking
because even on Ubuntu 20.04 fixincludes drops in it's own .
You need to check that
On Fri, Feb 04, 2022 at 10:26:07AM +0100, Martin Liška wrote:
> On 2/3/22 22:51, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote:
> > > On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> > > > On 2/3/22 19:44, Andreas Schwab wrote:
> > > > > On
Hi!
As mentioned in the PR, for C++98 we have diagnostics that expect
>> terminating template arguments to be a mistake for > > (C++11
said it has to be treated that way), while if user trying to spare the
spacebar doesn't separate > from following = or >> from following =,
the diagnostics is
On Fri, 4 Feb 2022, Jakub Jelinek wrote:
> On Fri, Feb 04, 2022 at 02:49:13PM +0100, Richard Biener wrote:
> > Any comments? I have mixed feelings with proposing this for GCC 12
> > but like to hear from others as well. I didn't try to evaluate
> > the quality of stack slot sharing before/after
On Fri, Feb 04, 2022 at 02:49:13PM +0100, Richard Biener wrote:
> Any comments? I have mixed feelings with proposing this for GCC 12
> but like to hear from others as well. I didn't try to evaluate
> the quality of stack slot sharing before/after this change besides
> fixing the testsuite
Hi Thomas,
On 04.02.22 10:37, Thomas Schwinge wrote:
I have attached a patch (not commited), which silences the three kind of
warnings and fixes the interface issue.
TODO: commit it.
Still "TODO: commit it" ;-) -- and while I haven't reviewed the changes
in detail, I did spot one item that
Since stack slot sharing now only works when RTL expansion
sees the point of birth of variables explicitely marked
we have to insert those markers during optimization.
One case is when CCP simplifies a VLA allocation done
with __builtin_stack_{save,restore} to a decl with constant size.
There we
This adjusts diagnostic passes for the birth CLOBBERs where
necessary. In particular the uninit diagnostics relies on particular
shaped IL to simplify the expression printed (to be cleaned up independently)
in gcc.dg/pr86058.c.
2022-02-02 Richard Biener
* tree-ssa-uninit.cc
Mostly decl shuffling, using patterns to make the scans less
error-prone and adjustments for now appearing birth CLOBBERs.
2022-02-02 Richard Biener
* gcc.dg/pr87052.c: Adjust.
* gcc.dg/tm/memopt-3.c: Likewise.
* gcc.dg/torture/pta-ptrarith-1.c: Likewise.
*
This adds explicit variable birth CLOBBERs in an attempt to fix
PR90348 and duplicates. The birth / death CLOBBER pairs are
used to compute liveness and conflicts for stack variable
coalescing where the lack of an explicit birth but instead
use of first mention causes misrepresentation of
On Thu, Feb 03, 2022 at 04:34:17PM -0500, Jason Merrill wrote:
> On 2/3/22 16:18, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
> > > > > I think it would be clearer to leave the !DECL_P case alone and add
> > > > >
> > > > > /* In C++ it is unspecified,
On 1/31/22 15:06, Martin Liška wrote:
> Hello.
>
> It's about 5 months since the last project status update:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html
> Now it's pretty clear that it won't be merged before GCC 12.1 gets released.
>
> So where we are? I contacted
Richard Biener writes:
> niter analysis uses multiple_of_p which currently assumes
> operations like MULT_EXPR do not wrap. We've got to rely on this
> for optimizing size expressions like those in DECL_SIZE and those
> generally use unsigned arithmetic with no indication that they
> are not
On Fri, Feb 04, 2022 at 02:25:17PM +0100, Richard Biener via Gcc-patches wrote:
> > Besides, have you actually run a regtest with that option? I'm asking
> > because even on Ubuntu 20.04 fixincludes drops in it's own .
> > You need to check that dropping that is actually safe.
>
> limits.h and
On Fri, Feb 4, 2022 at 2:08 PM Rainer Orth
wrote:
>
> Hi Martin,
>
> > It seems to me that fixincludes is hardy unused feature for nowadays header
> > files and so I'm suggesting a developer option that can skip the fixing.
>
> please remember that there's a world beyond current-day Linux.
>
> >
On Fri, Feb 4, 2022 at 12:50 PM Jakub Jelinek wrote:
>
> On Fri, Feb 04, 2022 at 12:14:33PM +0100, Richard Biener via Gcc-patches
> wrote:
> > +#define MAGIC 0x8000
> >
> > I _think_ writing the constant this way requires
>
> Perhaps use (~(uint32_t)0 / 2 + 1) as MAGIC instead?
> Then it
niter analysis uses multiple_of_p which currently assumes
operations like MULT_EXPR do not wrap. We've got to rely on this
for optimizing size expressions like those in DECL_SIZE and those
generally use unsigned arithmetic with no indication that they
are not expected to wrap. To preserve that
Hi Martin,
> It seems to me that fixincludes is hardy unused feature for nowadays header
> files and so I'm suggesting a developer option that can skip the fixing.
please remember that there's a world beyond current-day Linux.
> How is the feature used on other targets?
There are still quite a
May I please PING this?
Thanks,
Martin
On 1/25/22 14:04, Kito Cheng wrote:
Add -misa-spec to OPTION_DEFAULT_SPECS to make sure -misa-spec will
always pass that into assembler, that prevent GCC and binutils using
different way to interpret the ISA string.
gcc/ChangeLog:
PR
Hello.
It seems to me that fixincludes is hardy unused feature for nowadays header
files and so I'm suggesting a developer option that can skip the fixing.
How is the feature used on other targets?
Right now, fixinclude takes about 11 seconds on my machine, where
it reads (and applies regexes)
On Fri, Feb 04, 2022 at 12:14:33PM +0100, Richard Biener via Gcc-patches wrote:
> +#define MAGIC 0x8000
>
> I _think_ writing the constant this way requires
Perhaps use (~(uint32_t)0 / 2 + 1) as MAGIC instead?
Then it doesn't actually require that uint32_t actually is exactly 32 bits.
On the
On 2/2/22 09:30, Tobias Burnus wrote:
This patch updates the documentation for Tom's change of the default
-mptx= version - mentioning also -mptx=7.0.
I forgot whether ptx = 7.0 was working fine or whether there was
a reason not to mention it.
A ptx version is experimental if all sm versions
Already during parsing, the allocatable character array assignment
x = (x)
is converted to two gfc_codes with EXEC_ASSIGN, namely:
ASSIGN z1:_F.DA0(FULL) (parens z1:x(FULL))
ASSIGN z1:x(FULL) z1:_F.DA0(FULL)
But the current code expects only one gfc_code - as parse.c does some
checks,
On 04/02/2022 09:46, Thomas Schwinge wrote:
>
> Abid, are you going to address these? I think it does make sense if the
> C/C++ and Fortran test cases match as much as feasible.
>
Sure. I will do that.
> However: really (a) remove 'omp_alloctrait (omp_atk_pool_size, 8192)'
> altogether, or
Sorry, just realised I'd never replied to this.
Marc Poulhies writes:
> Eric Botcazou writes:
>>> The new variables seem to be unused, so I think slightly stronger
>>> DCE could remove the calls even after the patch. Perhaps the containing
>>> functions should take an int32x4_t *ptr or
On Thu, Feb 3, 2022 at 4:50 AM Arjun Shankar wrote:
>
> Expressions of the form "X + CST < Y + CST" where:
>
> * CST is an unsigned integer constant with only the MSB set, and
> * X and Y's types have integer conversion ranks <= CST's
>
> can be simplified to "(signed) X < (signed) Y".
>
> This
On Fri, 4 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 4 Feb 2022, Richard Sandiford wrote:
> >> Richard Biener via Gcc-patches writes:
> >> > niter analysis uses multiple_of_p which currently assumes
> >> > operations like MULT_EXPR do not wrap. We've got to rely on
Richard Biener writes:
> On Fri, 4 Feb 2022, Richard Sandiford wrote:
>> Richard Biener via Gcc-patches writes:
>> > niter analysis uses multiple_of_p which currently assumes
>> > operations like MULT_EXPR do not wrap. We've got to rely on this
>> > for optimizing size expressions like those in
On Fri, Feb 4, 2022 at 11:41 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> this completes my fix for PR debug/101947 by emptying the base_types vector
> before (re)populating it.
>
> Tested on x86_64-suse-linux, OK for the mainline?
OK.
>
> 2022-02-04 Eric Botcazou
>
> PR
Hi Thomas,
Very many thanks for your help investigating this problem.
> > This patch addresses the "increased register pressure" regression
> > on nvptx-none caused by my change to transition the backend to
> > a STORE_FLAG_VALUE = 1 target.
>
> Yes, "addresses", but unfortunately doesn't
Hello,
Le 29/01/2022 à 22:41, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
compiling with -fsanitize=undefined shows that we did mishandle the
case where a missing optional argument is passed to another procedure.
Besides the example given in the PR, the existing testcase
On Fri, 4 Feb 2022, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > niter analysis uses multiple_of_p which currently assumes
> > operations like MULT_EXPR do not wrap. We've got to rely on this
> > for optimizing size expressions like those in DECL_SIZE and those
> >
Hi,
this completes my fix for PR debug/101947 by emptying the base_types vector
before (re)populating it.
Tested on x86_64-suse-linux, OK for the mainline?
2022-02-04 Eric Botcazou
PR debug/104366
* dwarf2out.cc (dwarf2out_finish): Empty base_types.
Richard Biener via Gcc-patches writes:
> niter analysis uses multiple_of_p which currently assumes
> operations like MULT_EXPR do not wrap. We've got to rely on this
> for optimizing size expressions like those in DECL_SIZE and those
> generally use unsigned arithmetic with no indication that
On Fri, Feb 04, 2022 at 11:26:30AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Feb 04, 2022 at 11:14:05AM +0100, Eric Botcazou wrote:
> > > > --- a/gcc/match.pd
> > > > +++ b/gcc/match.pd
> > > > @@ -401,27 +401,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > > >
> > > > /* X /
On Fri, Feb 04, 2022 at 11:14:05AM +0100, Eric Botcazou wrote:
> > > --- a/gcc/match.pd
> > > +++ b/gcc/match.pd
> > > @@ -401,27 +401,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > >
> > > /* X / bool_range_Y is X. */
> > > (simplify
> > >
> > >(div @0 SSA_NAME@1)
> > >
> > > - (if
On Fri, 4 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > This removes the odd check of size_type_node when handling left-shifts
> > as multiplications of 1 << N and instead uses the type as specified.
> > It also moves left-shift handling next to multiplications where it
> >
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -401,27 +401,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >
> > /* X / bool_range_Y is X. */
> > (simplify
> >
> >(div @0 SSA_NAME@1)
> >
> > - (if (INTEGRAL_TYPE_P (type) && ssa_name_has_boolean_range (@1))
> > + (if
Richard Biener writes:
> This removes the odd check of size_type_node when handling left-shifts
> as multiplications of 1 << N and instead uses the type as specified.
> It also moves left-shift handling next to multiplications where it
> semantically belongs.
>
> Boostrap and regtest pending on
On Fri, Feb 04, 2022 at 10:53:22AM +0100, Eric Botcazou wrote:
> > Well, yes, we have to fix it.
>
> Here's the fix we agreed upon in the audit trail, OK for the mainline?
>
> PR tree-optimization/104356
> * match.pd (X / bool_range_Y is X): Add guard.
> (X / X is one):
Richard Sandiford via Gcc-patches writes:
> The main thing that makes truth vector types special is that those
> types are the only ones that allow multiple elements in the same byte.
> A “normal” 16-byte vector created by build_vector_type(_for_mode)
> cannot be smaller than 16 bytes.
Er, of
> Well, yes, we have to fix it.
Here's the fix we agreed upon in the audit trail, OK for the mainline?
PR tree-optimization/104356
* match.pd (X / bool_range_Y is X): Add guard.
(X / X is one): Likewise.
(X / abs (X) is X < 0 ? -1 : 1): Likewise.
(X / -X
Hi!
On 2022-01-31T19:13:09+, Hafiz Abid Qadeer wrote:
> On 25/01/2022 10:32, Tobias Burnus wrote:
>> On 25.01.22 10:19, Thomas Schwinge wrote:
I am trying to figure out if the problem you observed
is a general one or just specific to fortran testcase.
>>> So, unless the
Christophe Lyon writes:
> On Tue, Feb 1, 2022 at 4:42 AM Richard Sandiford
> wrote:
>
>> Christophe Lyon via Gcc-patches writes:
>> > On Mon, Jan 31, 2022 at 7:01 PM Richard Sandiford via Gcc-patches <
>> > gcc-patches@gcc.gnu.org> wrote:
>> >
>> >> Sorry for the slow response, was out last
The following improves early uninit diagnostics by computing edge
reachability using VN and ignoring unreachable blocks when looking
for uninitialized uses. To not ICE with -fdump-tree-all the
early uninit pass needs a dumpfile since VN tries to dump statistics.
Bootstrapped on
Hi Tobias!
On 2022-01-24T09:45:48+0100, Tobias Burnus wrote:
> On 21.01.22 18:43, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> 11 | integer(c_int) function is_64bit_aligned (a) bind(C)
>>> Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C)
On Fri, 4 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > The following happens to improve compile-time of the PR103641
> > testcase on aarch64 significantly. I did not investigate the
> > effect on the generated code but at least in theory
> > choose_mult_variant should do a
On 2/3/22 22:51, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote:
On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
On 2/3/22 19:44, Andreas Schwab wrote:
On Feb 03 2022, Martin Liška wrote:
+cd $LIB
+echo "$all_dirs" | xargs mkdir -p
+cd ..
+
On Fri, Feb 04, 2022 at 09:31:20AM +0100, Richard Biener wrote:
> The following happens to improve compile-time of the PR103641
> testcase on aarch64 significantly. I did not investigate the
> effect on the generated code but at least in theory
> choose_mult_variant should do a better job when we
Hi!
As an aside:
On 2022-02-03T21:00:50+, "Roger Sayle" wrote:
> the exact register usage of a nvptx kernel depends upon the version of
> the Cuda drivers being used (and the hardware)
Yeah, that's a "problem" -- or: "challenge"? ;-)
The GCC/nvptx back end is generating some rather
Richard Biener writes:
> The following happens to improve compile-time of the PR103641
> testcase on aarch64 significantly. I did not investigate the
> effect on the generated code but at least in theory
> choose_mult_variant should do a better job when we tell it
> the actual mode we are going
The following happens to improve compile-time of the PR103641
testcase on aarch64 significantly. I did not investigate the
effect on the generated code but at least in theory
choose_mult_variant should do a better job when we tell it
the actual mode we are going to use for the operations it
Hi Roger!
On 2022-02-03T21:00:50+, "Roger Sayle" wrote:
> This patch
Thanks!
> addresses the "increased register pressure" regression on
> nvptx-none caused by my change to transition the backend to a
> STORE_FLAG_VALUE = 1 target.
Yes, "addresses", but unfortunately doesn't "resolve".
Richard Sandiford writes:
> In this PR the waccess pass was fed:
>
> D.10779 ={v} {CLOBBER};
> VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES (addr_5(D),
> 64B, _2);
> _7 = D.10779.__val[0];
>
> However, the tracking of m_clobbers only looked at gassigns,
> so it missed that the clobber on
90 matches
Mail list logo
