It seems Clang doesn't support -fexcess-precision=xxx:
https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/clang_f_opts.c#L403
Thanks
Pengfei
-Original Message-
From: Hongtao Liu
Sent: Thursday, July 15, 2021 2:35 PM
To: Wang, Pengfei
Cc: Craig Topper ; Jakub Jelinek ;
Li
On Thu, Jul 15, 2021 at 10:07 AM Wang, Pengfei wrote:
>
> 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
> wa
On Tue, 13 Jul 2021, Jiufu Guo wrote:
> Major changes from v1:
> * Add target hook to query preferred doloop mode.
> * Recompute doloop iv base from niter under preferred mode.
>
> Currently, doloop.xx variable is using the type as niter which may shorter
> than word size. For some cases, it wou
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 weeks
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
--- a/
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, I
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
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
> >
* 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 con
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 2021/6/
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: gcc.d
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, Kewen.
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
+++ b/gcc/
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 false
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 don'
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 (IFN_MULH)
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 lib
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 co
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 hav
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.
>
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). */
> > +sta
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 wo
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 worse.
> 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, 202
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 counte
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 build_
Cherry picked from 84f7bab89279ca1234fef88929c74caeda8cb55e
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
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 85c22c517e9571d1f
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
4ed9f2e65a69e270ea47221318d6
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: Wed,
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
s
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 t
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 this
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:
> >>>
> >>> O
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 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! :-
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:. You
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 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 honours
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 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
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 to
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 t
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 s
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 vect
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 template
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
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 previ
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 out-of-
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
* gcc.target/powerpc/pp
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
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
> -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
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 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
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 o
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
TE
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++ knowledge
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, 64-bit),
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
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
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
> >
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 d
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 th
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 change
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 f
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 email,
>> and found the testing failed with the following case:
>>
>> #define
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 weeks which would result in the GCC 11.2
> release about thr
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 the attached patch fixes all issu
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, July 14, 2021 2:19 PM
> To: Tamar Christina
> Cc: Michael Matz ; Bernd Edlinger
> ; Richard Biener ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
>
> On Wed, Jul 14, 2
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 c9114f2804b91690e030383de15a2
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 +0
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 resulti
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,
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
'../build-x86_64-build_pc-linux-gnu/libcpp/l
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 c
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 no
On Fri, Jun 25, 2021 at 5:39 AM H.J. Lu wrote:
>
> On Fri, Jun 25, 2021 at 12:50 AM Uros Bizjak wrote:
> >
> > On Fri, Jun 25, 2021 at 4:51 AM Hongtao Liu wrote:
> > >
> > > On Fri, Jun 25, 2021 at 12:13 AM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Jun 24, 2021 at 2:12 PM
"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 (IFN_MULH): New internal function.
>>> * tree-vect-patterns.
On Wed, Jul 14, 2021 at 10:21 AM Trevor Saunders wrote:
>
> 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?
OK.
Richard.
> Trev
>
> gcc/ChangeLog:
>
> * cfgexpand.c (exp
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 x
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): Likewis
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
> told was the proper location. To avoid using the global we need the caller to
>
This adds a conditional noexcept to the C++20 constructor. The
std::to_address call cannot throw, so only taking the difference of the
two iterators can throw.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(It, End)): Add
noex
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
> >>> addr
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 ne
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 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.
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 (vect_recog_mulhs_pattern):
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
> -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 I
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
0002-AArc
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
templ
"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 IFN_M
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.
* config/arm/aarch-com
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:
* tree-diagnosti
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 insertions(
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 mak
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 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 Biener
1 - 100 of 109 matches
Mail list logo
