On 7/14/21 11:26 AM, Patrick Palka wrote:
Here we're incorrectly treating T&& as a forwarding reference during
CTAD even though T is a template parameter of the class template.
This happens because the template parameter T in the out-of-line
definition of the constructor doesn't have the flag
I forgot to add the patch when I reposted this.
PR 100170: Fix eq/ne tests on power10.
This patch updates eq/ne tests in the testsuite to adjust the test if
power10 code generation is used.
2021-07-04 Michael Meissner
gcc/testsuite/
PR testsuite/100170
*
The uses of vec in get_all_loop_exits and process_conditional were memory
leaks, as .release() was never called for them. The other changes are some
cases that did have proper release handling, but it's simpler to leave
releasing to the auto_vec destructor.
Tested x86_64-pc-linux-gnu, applying
On 7/14/21 2:47 PM, Tamar Christina wrote:
> Hi,
>
> Ever since this commit
>
> commit c9114f2804b91690e030383de15a24e0b738e856
> Author: Bernd Edlinger
> Date: Fri May 28 06:27:27 2021 +0200
>
> Various tools have been having trouble with cross compilation resulting in
>
> make[2]: *** No
On 7/14/21 10:46 AM, Martin Sebor wrote:
On 7/13/21 9:39 PM, Jason Merrill wrote:
On 7/13/21 4:02 PM, Martin Sebor wrote:
On 7/13/21 12:37 PM, Jason Merrill wrote:
On 7/13/21 10:08 AM, Jonathan Wakely wrote:
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
Somebody with more C++
On Wed, Jul 14, 2021 at 10:12:46AM +0800, Kewen.Lin wrote:
> on 2021/7/14 上午6:07, Segher Boessenkool wrote:
> > Hi!
> >
> > On Tue, Jul 13, 2021 at 04:58:42PM +0800, Kewen.Lin wrote:
> >> This patch is to make Power10 newly introduced vector
> >> multiply high (part) instructions exploited in
On 7/13/21 9:39 PM, Jason Merrill wrote:
On 7/13/21 4:02 PM, Martin Sebor wrote:
On 7/13/21 12:37 PM, Jason Merrill wrote:
On 7/13/21 10:08 AM, Jonathan Wakely wrote:
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
Somebody with more C++ knowledge than me needs to approve the
vec.h
Here we're incorrectly treating T&& as a forwarding reference during
CTAD even though T is a template parameter of the class template.
This happens because the template parameter T in the out-of-line
definition of the constructor doesn't have the flag
TEMPLATE_TYPE_PARM_FOR_CLASS set, and during
Hi Mike,
On 7/7/21 2:58 PM, Michael Meissner wrote:
[PATCH] Fix long double tests when default long double is not IBM.
This patch adds 3 more selections to target-supports.exp to see if we can force
the compiler to use a particular long double format (IEEE 128-bit, IBM extended
double,
Hi, Kees,
> On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote:
>> Hi, Richard,
>>
>>> On Jul 14, 2021, at 2:14 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
Hi, Kees,
I
On 7/14/21 9:56 AM, Marek Polacek wrote:
On Wed, Jul 14, 2021 at 12:15:48AM -0400, Jason Merrill wrote:
On 7/13/21 8:15 PM, Marek Polacek wrote:
This PR gave me a hard time: I saw multiple issues starting with
different revisions. But ultimately the root cause seems to be
the following, and
On 7/14/21 1:52 PM, Patrick Palka wrote:
On Wed, 14 Jul 2021, Jason Merrill wrote:
On 7/14/21 11:26 AM, Patrick Palka wrote:
Here we're incorrectly treating T&& as a forwarding reference during
CTAD even though T is a template parameter of the class template.
This happens because the
On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote:
> Hi, Richard,
>
> > On Jul 14, 2021, at 2:14 AM, Richard Biener
> > wrote:
> >
> > On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
> >>
> >> Hi, Kees,
> >>
> >> I took a look at the kernel testing case you attached in the previous
On Wed, Jul 14, 2021 at 09:39:42AM +0200, Richard Biener via Gcc-help wrote:
> On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote:
> > >
> > > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
>
On Wed, 14 Jul 2021, Jason Merrill wrote:
> On 7/14/21 11:26 AM, Patrick Palka wrote:
> > Here we're incorrectly treating T&& as a forwarding reference during
> > CTAD even though T is a template parameter of the class template.
> >
> > This happens because the template parameter T in the
> -Original Message-
> From: Bernd Edlinger
> Sent: Wednesday, July 14, 2021 4:56 PM
> To: Tamar Christina ; Michael Matz
>
> Cc: gcc-patches@gcc.gnu.org; Richard Biener
> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
>
> On 7/14/21 2:47 PM, Tamar Christina
Hi All,
The lines being removed have been updated and merged into a new
condition. But when resolving some conflicts I accidentally
reintroduced them causing some test failes.
This removes them.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Committed as the changes were
On Wed, Jul 14, 2021 at 12:32:24PM +0100, Richard Sandiford wrote:
> TBH, 79 vs. 80 isn't normally something I'd worry about when reviewing
> new code. But I know in the past people have asked for 79 to be used
> for the “end+1” reason, so I don't think we should “fix” existing code
> that
On Wed, Jul 14, 2021 at 11:11:29AM -0500, Bill Schmidt wrote:
> Just for my edification, can you remind me why we need -Wno-psabi?
> What warning are we disabling? Same question for ieee variant.
>
> LGTM in any event. Recommend approval by maintainers...
Unless you configured GCC with a 2.32
Hi!
On Wed, Jul 14, 2021 at 06:26:28PM +0800, guojiufu wrote:
> PR target/61837
Wrong PR number?
> +@deftypefn {Target Hook} machine_mode TARGET_PREFERRED_DOLOOP_MODE
> (machine_mode @var{mode})
> +This hook takes a @var{mode} which is the original mode of doloop IV.
> +And if the target
On 7/14/21 1:01 AM, Richard Biener wrote:
On Tue, Jul 13, 2021 at 9:27 PM Martin Sebor via Gcc-patches
wrote:
An existing, previously xfailed test that I recently removed
the xfail from made me realize that -Wstringop-overflow doesn't
properly detect buffer overflow resulting from vectorized
On 7/12/21 5:02 AM, Richard Biener wrote:
On Wed, Jul 7, 2021 at 4:37 PM Martin Sebor wrote:
On 7/7/21 1:28 AM, Richard Biener wrote:
On Tue, Jul 6, 2021 at 5:06 PM Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573968.html
Any questions/suggestions on the
On Wed, Jul 14, 2021 at 12:45 AM Hongtao Liu via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> > >
> > Set excess_precision_type to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 to
> > round after each operation could keep semantics right.
> > And I'll document the behavior difference between soft-fp and
> >
On Jul 13, 2021, Alexandre Oliva wrote:
> On Jul 13, 2021, Richard Biener wrote:
>> oops - also worth backporting to affected branches.
> Thanks, I took that as explicit approval and put it in.
> attr fnspec is new in gcc-11, not present in gcc-10, so I'm testing a
> trivial backport, just to
With the integration of the relational oracle, Ranger is now pretty much
at parity in getting all the cases EVRP use to, and runs the testsuite
cleanly.
This patch turns hybrid mode off, running EVRP in ranger-only mode. It
requires a tweak to one test case which was XFAILing before, but now
On Wed, Jul 14, 2021 at 03:25:32PM -0500, Segher Boessenkool wrote:
> Please do not send the same patches in a new thread. It is much more
> work to keep track of. Just ping patches by replying to them (either
> copy the list or not, either works). Thanks!
Oh, and do not edit the Subject:.
On Wed, Jul 14, 2021 at 8:01 PM Alan Modra wrote:
>
> On Wed, Jun 30, 2021 at 05:06:30PM -0300, Tulio Magno Quites Machado Filho
> wrote:
> > Alan Modra via Gcc-patches writes:
> >
> > > Compiling gcc/testsuite/gcc.dg/split-*.c and others with -mcpu=power10
> > > and linking with a non-pcrel
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/6/28 下午3:00, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> I'd like to gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
>
>
> BR,
> Kewen
>
> on
On Linux/x86_64,
1e0ab1c4ba6159ad7ce71c6cddd5e04d2a636742 is the first bad commit
commit 1e0ab1c4ba6159ad7ce71c6cddd5e04d2a636742
Author: Tamar Christina
Date: Wed Jul 14 15:21:40 2021 +0100
middle-end: Add tests middle end generic tests for sign differing
dotproduct.
caused
FAIL:
Please do not send the same patches in a new thread. It is much more
work to keep track of. Just ping patches by replying to them (either
copy the list or not, either works). Thanks!
Segher
On Wed, Jul 14, 2021 at 01:52:05PM -0400, Michael Meissner wrote:
> This patch updates eq/ne tests in the testsuite to adjust the test if
> power10 code generation is used.
eq0/ne0.
> --- a/gcc/testsuite/gcc.target/powerpc/ppc-eq0-1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/ppc-eq0-1.c
> -/* {
On Wed, Jul 14, 2021 at 07:30:45PM +, Qing Zhao wrote:
> Hi, Kees,
>
>
> > On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
> >
> > On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote:
> >> Hi, Richard,
> >>
> >>> On Jul 14, 2021, at 2:14 AM, Richard Biener
> >>> wrote:
> >>>
> >>>
The following \3 patches were applied to releases/gcc-11. They form the
bulk of the on-entry fixes in trunk
d3344fbe7bc25f414671ad7a37d2e9601942597d
Clean up and virtualize the on-entry cache interface. cherry picked
from 14b0f37a644d7b59e1737fb275ec4fff044972a8
On Wed, Jun 30, 2021 at 05:06:30PM -0300, Tulio Magno Quites Machado Filho
wrote:
> Alan Modra via Gcc-patches writes:
>
> > Compiling gcc/testsuite/gcc.dg/split-*.c and others with -mcpu=power10
> > and linking with a non-pcrel libgcc results in crashes due to the
> > power10 pcrel code not
On Wed, Jul 14, 2021 at 01:27:54PM +0200, Richard Biener wrote:
> On Wed, Jul 14, 2021 at 10:20 AM Trevor Saunders
> wrote:
> >
> > prior to this commit all calls to build_decl used input_location, even if
> > temporarily until build_decl reset the location to something else that it
> > was
>
We have disabled the poor value cache in trunk as not providing enough
benefit for the cost. do the same in gcc 11.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
>From 86534c07a390e240ffea51653945de85df7a3632 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date:
Cherry picked from 84f7bab89279ca1234fef88929c74caeda8cb55e
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
>From b977e6b29c67be81df882d1f5cc7eb6a5d8c98a0 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 30 Jun 2021 14:15:53 -0400
Subject: [PATCH 8/8] Fix
Hi!
On Fri, Jul 09, 2021 at 02:32:59PM -0500, will schmidt wrote:
> On Thu, 2021-06-17 at 10:18 -0500, Bill Schmidt via Gcc-patches wrote:
> > 2021-06-07 Bill Schmidt
> > +/* Pass over unprintable characters and whitespace (other than a newline,
> > + which terminates the scan). */
> >
Hi,
I would like to have an early ping on this with more mail addresses.
BR,
Jiufu.
On 2021-07-07 20:47, Jiufu Guo wrote:
Changes since v1:
* Update assumptions for niter, add more test cases check
* Use widest_int/wide_int instead mpz to do +-/
* Move some early check for quick return
For
On 7/13/21 5:59 PM, Segher Boessenkool wrote:
>> - && adjacent_mem_locations (str_mem, str_mem2))
>> + && adjacent_mem_locations (str_mem, str_mem2) != NULL_RTX)
>
> ... so don't change this? Or write != 0 != 0 != 0, if one time is good,
> three times must be better!
Short cut version to disable processing of debug statements by ranger in
GCC 11.
Although PR 100781 is not an issue in GCC11, its possible that a similar
situation may arise. The identical fix cannot be easily introduced.
With EVRP always running in hybrid mode, there is no need for ranger to
Cherry picked from 84f7bab89279ca1234fef88929c74caeda8cb55e
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
> On Jul 14, 2021, at 4:23 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 07:30:45PM +, Qing Zhao wrote:
>> Hi, Kees,
>>
>>
>>> On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
>>>
>>> On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote:
Hi, Richard,
> On Jul 14,
On Sun, 2021-07-11 at 12:58 -0400, Lewis Hyatt wrote:
> Hi David-
>
> I thought this might be a good opportunity to ask about the patch
> that
> supports -finput-charset in diagnostic.c please?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564527.html
>
> The patch will require some
on 2021/7/14 下午7:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/7/14 下午4:38, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
gcc/ChangeLog:
* internal-fn.c (first_commutative_argument): Add info for IFN_MULH.
* internal-fn.def
External declarations in ./gcc/toplev.h is no longer used in newest
version of gcc and should be cleaned up to avoid misunderstandings.
gcc/ChangeLog:
* toplev.h (set_random_seed):
---
diff --git a/gcc/toplev.h b/gcc/toplev.h
index 175944c..f543554 100644
--- a/gcc/toplev.h
+++
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/6/28 下午3:01, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
>
> BR,
> Kewen
>
> on 2021/6/9 上午10:26,
On Wed, Jul 14, 2021 at 04:51:52PM -0500, Bill Schmidt wrote:
> Hi Mike,
>
> On 7/14/21 4:42 PM, Michael Meissner wrote:
> >Fix regular expression error in PR 100166 patch
> >
> >In my patch for PR testsuite/100166 (which fixes various tests so that the
> >plxv and pstxv instructions can be
hi!
On Wed, Jul 07, 2021 at 03:58:37PM -0400, Michael Meissner wrote:
> +/* We force the long double type to be IBM 128-bit because the
> CONVERT_TO_PINF
There is no "forcing" here. "We use ..." or "We require ..." is fine.
"Force" suggests something tries to prevent you.
"Override" is
on 2021/7/15 上午3:32, Segher Boessenkool wrote:
> On Wed, Jul 14, 2021 at 12:32:24PM +0100, Richard Sandiford wrote:
>> TBH, 79 vs. 80 isn't normally something I'd worry about when reviewing
>> new code. But I know in the past people have asked for 79 to be used
>> for the “end+1” reason, so I
Access warnings look through calls to the subset of built-ins
that return one of their pointer arguments to find the object
the pointer it points to and its offset. The computation is
wrong for functions like stpcpy, stpncpy and mempcpy that
return a pointer plus some offset, and leads to a
Fix regular expression error in PR 100166 patch
In my patch for PR testsuite/100166 (which fixes various tests so that the
plxv and pstxv instructions can be counted as legitimate instructions), I
had a typo in the pr86731-fwrapv-longlong.c test (using plvx instead of
plxv). This patch fixes
Hi Mike,
On 7/14/21 4:42 PM, Michael Meissner wrote:
Fix regular expression error in PR 100166 patch
In my patch for PR testsuite/100166 (which fixes various tests so that the
plxv and pstxv instructions can be counted as legitimate instructions), I
had a typo in the pr86731-fwrapv-longlong.c
If the on-entry cache cannot properly represent a range, do not continue
trying to propagate it. Adapted version of a GCC 12 patch which works
in conjuction with the sparse on entry cache update.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
>From
Many of the types from cp-tree.def were only marked as having tree_common,
when actually most of them have type_non_common. This broke
g++.dg/modules/xtreme-header-2, as the modules code relies on
tree_contains_struct to know what bits it needs to stream.
We don't seem to use type_non_common for
Hi!
On Thu, Jun 17, 2021 at 10:18:49AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-gen-builtins.c (consume_whitespace): New
> function.
> (advance_line): Likewise.
> (safe_inc_pos): Likewise.
> (match_identifier): Likewise.
> (match_integer): Likewise.
* Clang for AArch64 promotes each individual operation and rounds
immediately afterwards. https://godbolt.org/z/qzGfv6nvo note the fcvts between
the two fadd operations. It's implemented in the LLVM backend where we can't
see what was originally a single expression.
Yes, but this is not
On Wed, 14 Jul 2021, H.J. Lu wrote:
> On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote:
> >
> >
> > Status
> > ==
> >
> > The GCC 11 branch is open for regression and documentation fixes.
> > It's time for a GCC 11.2 release and we are aiming for a release
> > candidate in about two
On 2021-07-15 02:04, Segher Boessenkool wrote:
Hi!
On Wed, Jul 14, 2021 at 06:26:28PM +0800, guojiufu wrote:
PR target/61837
Wrong PR number?
There is a patch optimize "add -1; zero_ext; add +1" to "zero_ext"
already.
Having this patch would help to avoid the left 'zero_ext', so,
fyi, in case I forget to sign off, all my commits this year forwards are under
the DCO (as I do not have an assignment).
Trev
Signed-off-by: Trevor Saunders
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 48cfa3fda1d..7cb63e5f62b 100644
---
On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote:
> >
> > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> > > On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > > > Hi:
> > > > The
On Fri, Jul 9, 2021 at 11:32 AM Richard Biener wrote:
>
> The driver amends assembler options with for example --gdwarf-5
> when debugging is enabled but the check for that does not consider
> the effect of -gtoggle which is not handled in the common option
> machinery. The following alters
On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote:
>
> On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> > On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > > Hi:
> > > The original problem was that some users wanted the cmdline option
> > >
> > > -ffast-math
On Wed, Jul 14, 2021 at 5:11 AM guojiufu via Gcc-patches
wrote:
>
> On 2021-07-13 23:38, Segher Boessenkool wrote:
> > On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote:
> >> On Fri, 9 Jul 2021, Segher Boessenkool wrote:
> >> > Almost all targets just use Pmode, but there is no such
On Wed, Jul 14, 2021 at 7:10 AM Alexandre Oliva wrote:
>
> On Jul 13, 2021, Richard Biener wrote:
>
> > Hmm, elsewhere in this function we're not anticipating future removal but
> > instead use ->global_info_ready which IIRC is when the unit was
> > initially analyzed. So don't the other uses
> >
> Set excess_precision_type to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 to
> round after each operation could keep semantics right.
> And I'll document the behavior difference between soft-fp and
> AVX512FP16 instruction for exceptions.
I got some feedback from my colleague who's working on
If the -fprofile-info-section is used, then the gcov information is registered
in a linker set. This is done by build_gcov_info_var_registration(). The
compiler generated object placed in the section was not marked as referenced,
so once optimization was enabled, this object was optimized away.
On Tue, Jul 13, 2021 at 9:27 PM Martin Sebor via Gcc-patches
wrote:
>
> An existing, previously xfailed test that I recently removed
> the xfail from made me realize that -Wstringop-overflow doesn't
> properly detect buffer overflow resulting from vectorized stores.
> Because of a difference in
On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
>
> Hi, Kees,
>
> I took a look at the kernel testing case you attached in the previous email,
> and found the testing failed with the following case:
>
> #define INIT_STRUCT_static_all = { .one = arg->one,\
>
OK?
On Wednesday, 30 June 2021 10:59:28 CEST Matthias Kretz wrote:
> Library code, especially in headers, sometimes needs to know how the
> compiler interprets / optimizes floating-point types and operations.
> This information can be used for additional optimizations or for
> ensuring
on 2021/7/14 下午2:38, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>>
>> on 2021/7/13 下午8:42, Richard Biener wrote:
>>> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
Hi Richi,
Thanks for the comments!
on 2021/7/13 下午5:35, Richard
On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>
> on 2021/7/13 下午8:42, Richard Biener wrote:
> > On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
> >>
> >> Hi Richi,
> >>
> >> Thanks for the comments!
> >>
> >> on 2021/7/13 下午5:35, Richard Biener wrote:
> >>> On Tue, Jul 13, 2021 at 10:53 AM
On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > Hi:
> > The original problem was that some users wanted the cmdline option
> >
> > -ffast-math not to act on intrinsic production code.
This sounds like the users
On Wed, Jul 14, 2021 at 3:45 AM Alexandre Oliva wrote:
>
> On Jul 13, 2021, Richard Biener wrote:
>
> > oops - also worth backporting to affected branches.
>
> Thanks, I took that as explicit approval and put it in.
>
> attr fnspec is new in gcc-11, not present in gcc-10, so I'm testing a
>
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Jul 14, 2021, Richard Biener via Gcc-patches wrote:
> Can you put the above (and maybe your patch) into a PR so it doesn't
> get lost?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101454
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist
As I was discussing with richi, I don't think it makes sense to protect
calls to pure/const functions from DCE just because they aren't explicitly
declared noexcept. PR100382 indicates that there are different
considerations for Go, which has non-call exceptions. But still turn the
flag off for
Hi Harald,
we rather shouldn't consider a presence check for a non-dummy variable.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
OK for all.
Thanks for the patch!
Best regards
Thomas
On 2021-07-14 12:40, guojiufu via Gcc-patches wrote:
Updated the patch as below:
Thanks for comments.
gcc/ChangeLog:
2021-07-13 Jiufu Guo
PR target/61837
* config/rs6000/rs6000.c (TARGET_PREFERRED_DOLOOP_MODE): New hook.
(rs6000_preferred_doloop_mode): New hook.
On Wed, 14 Jul 2021 at 04:56, Jason Merrill wrote:
>
> On 7/12/21 3:58 PM, Jonathan Wakely wrote:
> > On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote:
> >>
> >> On 6/26/21 10:23 AM, Andrew Sutton wrote:
> >>>
> >>> I ended up taking over this work from Jeff (CC'd on his existing email
> >>>
prior to this commit all calls to build_decl used input_location, even if
temporarily until build_decl reset the location to something else that it was
told was the proper location. To avoid using the global we need the caller to
pass in the location it wants, however that's not possible with
bootstrapped and regtested on x86_64-linux-gnu, ok?
Trev
gcc/ChangeLog:
* cfgexpand.c (tree_conflicts_with_clobbers_p): Pass location to
diagnostics.
(expand_asm_stmt): Likewise.
---
gcc/cfgexpand.c | 35 ++-
1 file changed, 18
Hi Richard,
on 2021/7/14 下午4:38, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> gcc/ChangeLog:
>>
>> * internal-fn.c (first_commutative_argument): Add info for IFN_MULH.
>> * internal-fn.def (IFN_MULH): New internal function.
>> * tree-vect-patterns.c
So the hook can use it as the location of diagnostics.
bootstrapped and regtested on x86_64-linux-gnu, also tested one make all-gcc
for each effected cpu, ok?
Trev
gcc/ChangeLog:
* cfgexpand.c (expand_asm_loc): Adjust.
(expand_asm_stmt): Likewise.
*
It appears that input_location was used here before the diagnostic's location
was available, and never updated, when the other part of the header was added
that uses it, so this makes it consistent.
bootstrapped and regtested on x86_64-linux-gnu, ok?
Trev
gcc/ChangeLog:
*
Hi,
Like previous patch, this is found when I was playing with stx::simd. It's an
obvious
change as described in commit summary. Also the dead store in the code should
be
optimized away, but I guess there is no guarantee, so here is a simple patch
fixing it.
Is it OK?
Thanks,
bin
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of bin.cheng via
> Gcc-patches
> Sent: 14 July 2021 10:19
> To: GCC Patches
> Subject: [PATCH AArch64]Use stable sort in generating ldp/stp
>
> Hi,
> Like previous patch, this is found when
The following fixes the IV adjustment for the gap in a negative
stride SLP vectorization. The adjustment was in the wrong direction,
now fixes as in the patch.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-07-14 Richard Biener
PR tree-optimization/101445
On Wed, 14 Jul 2021 at 04:39, Jason Merrill wrote:
>
> On 7/13/21 4:02 PM, Martin Sebor wrote:
> > On 7/13/21 12:37 PM, Jason Merrill wrote:
> >> On 7/13/21 10:08 AM, Jonathan Wakely wrote:
> >>> On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
> Somebody with more C++ knowledge than me
On Tue, Jul 13, 2021 at 9:35 PM Hongtao Liu wrote:
>
> On Wed, Jul 14, 2021 at 10:34 AM liuhongt wrote:
> >
> > By optimizing vector movement to broadcast in ix86_expand_vector_move
> > during pass_expand, pass_reload/LRA can automatically generate an avx512
> > embedded broadcast, pass_cpb is
On Wed, Jul 14, 2021 at 12:32 AM Matthias Kretz wrote:
>
> OK?
>
> On Wednesday, 30 June 2021 10:59:28 CEST Matthias Kretz wrote:
> > Library code, especially in headers, sometimes needs to know how the
> > compiler interprets / optimizes floating-point types and operations.
> > This information
Hi,
Ever since this commit
commit c9114f2804b91690e030383de15a24e0b738e856
Author: Bernd Edlinger
Date: Fri May 28 06:27:27 2021 +0200
Various tools have been having trouble with cross compilation resulting in
make[2]: *** No rule to make target
Ping**2
On Juli 8, 2021 I wrote:
*Ping*
I intent to incorporate Sandra's suggestions, except for the beginning of line
spacing - that's needed to avoid exceeding the 80 character line limit. I did
not include an updated patch as just pinging is easier on a mobile during
vacation :-)
Thanks,
On Wed, Jul 14, 2021 at 2:48 PM Tamar Christina via Gcc-patches
wrote:
>
> Hi,
>
> Ever since this commit
>
> commit c9114f2804b91690e030383de15a24e0b738e856
> Author: Bernd Edlinger
> Date: Fri May 28 06:27:27 2021 +0200
>
> Various tools have been having trouble with cross compilation
On Wed, Jul 14, 2021 at 3:12 PM Richard Biener
wrote:
>
> On Wed, Jul 14, 2021 at 2:48 PM Tamar Christina via Gcc-patches
> wrote:
> >
> > Hi,
> >
> > Ever since this commit
> >
> > commit c9114f2804b91690e030383de15a24e0b738e856
> > Author: Bernd Edlinger
> > Date: Fri May 28 06:27:27 2021
On Wed, Jul 14, 2021 at 3:15 PM Richard Biener
wrote:
>
> On Wed, Jul 14, 2021 at 3:12 PM Richard Biener
> wrote:
> >
> > On Wed, Jul 14, 2021 at 2:48 PM Tamar Christina via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > >
> > > Ever since this commit
> > >
> > > commit
"Kewen.Lin" writes:
> gcc/ChangeLog:
>
> * internal-fn.c (first_commutative_argument): Add info for IFN_MULH.
> * internal-fn.def (IFN_MULH): New internal function.
> * tree-vect-patterns.c (vect_recog_mulhs_pattern): Add support to
> recog normal multiply highpart as
Hi,
I ran into a wrong code bug in code with deep template instantiation when
working on sdx::simd.
The root cause as described in commit summary is we skip prologue insns in
init_alias_analysis.
This simple patch fixes the issue, however, it's hard to reduce a case because
of heavy use of
On Wed, Jul 14, 2021 at 10:20 AM Trevor Saunders wrote:
>
> bootstrapped and regtested on x86_64-linux-gnu, ok?
OK.
Thanks,
Richard.
> Trev
>
> gcc/ChangeLog:
>
> * cfgexpand.c (tree_conflicts_with_clobbers_p): Pass location to
> diagnostics.
> (expand_asm_stmt):
On Wed, Jul 14, 2021 at 10:21 AM Trevor Saunders wrote:
>
> It appears that input_location was used here before the diagnostic's location
> was available, and never updated, when the other part of the header was added
> that uses it, so this makes it consistent.
>
> bootstrapped and regtested on
1 - 100 of 109 matches
Mail list logo
