Hello, Eric,
Thanks for looking into this.
On Aug 1, 2022, Eric Gallager via Gcc-patches wrote:
>> This just reassigns the value that was retrieved a couple of lines
>> above from the very same variable.
> Oh, ok, so I guess this isn't necessary after all?
Yeah, I don't see how this patch
This adds a clarifying "note" to address space mismatch diagnostics.
For example, it improves the diagnostic for
gcc.target/i386/addr-space-typeck-2.c from:
addr-space-typeck-2.c: In function 'test_bad_call':
addr-space-typeck-2.c:12:22: error: passing argument 2 of 'expects_seg_gs'
from
Pushed to trunk as r13-1921-gffd12be1394a49.
gcc/ChangeLog:
* doc/invoke.texi (-Wanalyzer-putenv-of-auto-var): Fix copy
error.
Signed-off-by: David Malcolm
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi
Hello-
This backport from r13-1596 to GCC 12 has been committed after
pre-approval. This was a straightforward cherry-pick from master with no
adjustments needed. I would like to note that subsequent to r13-1596, Thomas
made a few commits to the libgomp testsuite to test for new diagnostic
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
*
On 8/1/22 3:13 PM, Joseph Myers wrote:
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
new file mode 100644
index 000..3456105563a
--- /dev/null
+++
Hi!
On Mon, Jul 25, 2022 at 01:11:47PM +0800, HAO CHEN GUI wrote:
> +(define_insn "madddi4_lowpart"
> + [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> + (subreg:DI
> + (plus:TI
> + (mult:TI (any_extend:TI
> +(match_operand:DI 1 "gpc_reg_operand" "r"))
>
On Mon, Aug 1, 2022 at 12:05 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
> >
> > On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> > >
> > > On Jul 27, 2022, "H.J. Lu" wrote:
> > >
> > > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > >
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> new file mode 100644
> index 000..3456105563a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> @@
On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
>
> On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> >
> > On Jul 27, 2022, "H.J. Lu" wrote:
> >
> > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > > wrote:
> >
> > >> The use of @GOTOFF for locally-bound but externally-visible
On 7/26/22 14:58, Indu Bhagat wrote:
> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote:
>>
>> Contrary to CTF and our previous expectations, as per [1], turns out
>> that in BTF:
>>
>> 1) The `encoding' field in integer types shall not be treated as a
>> bitmap, but as an
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics). This change modifies the
-Wc++20-compat
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
*
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653. The changes include:
- Change of type for UTF-8 string literals from array of const char to
array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new
> On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote:
>>
>> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
>> annotation reflecting the linkage of functions (static, global). For
>> whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
>> instead
On Mon, Aug 01, 2022 at 02:19:32PM +0800, Kewen.Lin wrote:
> > new file mode 100644
> > index 000..256e05d5677
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr103109.c
> > @@ -0,0 +1,16 @@
> > +/* { dg-do compile { target { lp64 } } } */
>
> Since the guard is
Hi!
On Mon, Jul 25, 2022 at 01:11:47PM +0800, HAO CHEN GUI wrote:
> This patch adds an expand and several insns for multiply-add with
> three 64bit operands.
> PR target/103109
> * config/rs6000/rs6000.md (maddditi4): New pattern for
> multiply-add.
Please don't break lines
On Mon, Aug 1, 2022 at 3:54 AM Andreas Schwab wrote:
>
> On Jul 31 2022, Eric Gallager via Gcc-patches wrote:
>
> > It just makes the configure script respect the --with-build-time-tools
> > flag.
>
> Why does it make any difference?
>
See the original bug report:
> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Thanks a lot for your comments and suggestions. (And sorry for my late
>> reply).
>>
>>> On Jul 28, 2022, at 3:26 AM, Richard Biener wrote:
>>>
>>> On Tue, 19 Jul 2022,
On Mon, Aug 1, 2022 at 3:43 PM Roger Sayle wrote:
>
>
> This patch resolves PR target/106481, and is an oversight in my recent
> battles with REG_EQUAL notes during TImode STV (see PR target/106278
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html).
>
> The patch above's/current
> On Aug 1, 2022, at 3:13 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>>
>>
>>> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>>>
>>> On Tue, 19 Jul 2022, Qing Zhao wrote:
>>>
From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
The following builds upon the logic of the PR105679 fix by avoiding
to thread to a known edge that is predicted as probably never executed.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/106495
* tree-ssa-threadbackward.cc
This patch resolves PR target/106481, and is an oversight in my recent
battles with REG_EQUAL notes during TImode STV (see PR target/106278
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html).
The patch above's/current behaviour is that we check that the mode of
the REG_EQUAL note
Here is the patch that I pushed. Thanks for the feedback.
Thanks
-Sam
On Thu, Jul 28, 2022 at 3:03 AM Richard Biener
wrote:
> On Wed, Jul 27, 2022 at 9:57 PM Sam Feifer wrote:
> >
> >
> >> _Complex int are strange beasts, I'd simply avoid the transform for
> them.
> >>
> >
> > I added to the
On Mon, 1 Aug 2022, Andre Vieira (lists) wrote:
>
> On 29/07/2022 11:52, Richard Biener wrote:
> > On Fri, 29 Jul 2022, Jakub Jelinek wrote:
> >
> >> On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via
> >> Gcc-patches wrote:
> >>> The 'only on the vectorized code path' remains
On 30/07/2022 20:57, Jeff Law via Gcc-patches wrote:
On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote:
A SET operation that writes memory may have the same value as an
earlier store but if the alias sets of the new and earlier store do
not conflict then the set is not truly
On 29/07/2022 11:52, Richard Biener wrote:
On Fri, 29 Jul 2022, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vectorized code
On 29/07/2022 11:31, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vectorized code path right?
if conversion (in some cases)
Changes v4 -> v5: Fix changelog. No code change.
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from
Pushed as obvious.
Martin
PR lto/106170
lto-plugin/ChangeLog:
* configure.ac: Replace $target with $host.
* configure: Regenerate.
---
lto-plugin/configure| 2 +-
lto-plugin/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
> On 1 Aug 2022, at 09:21, Richard Biener via Gcc-patches
> wrote:
>
> On Sun, 31 Jul 2022, Iain Sandoe wrote:
>
>> Hi Richi,
>>
>>> On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches
>>> wrote:
>>>
>>> The following makes the backward threader reject threads whose entry
>>> edge
On Sun, 31 Jul 2022, Iain Sandoe wrote:
> Hi Richi,
>
> > On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches
> > wrote:
> >
> > The following makes the backward threader reject threads whose entry
> > edge is probably never executed according to the profile. That in
> > particular, for
On Jul 31 2022, Eric Gallager via Gcc-patches wrote:
> It just makes the configure script respect the --with-build-time-tools
> flag.
Why does it make any difference?
> diff --git a/configure b/configure
> index 65d7078dbe7..4d46b94ebc4 100755
> --- a/configure
> +++ b/configure
> @@ -12850,7
On Fri, 29 Jul 2022, Qing Zhao wrote:
> Hi, Richard,
>
> Thanks a lot for your comments and suggestions. (And sorry for my late reply).
>
> > On Jul 28, 2022, at 3:26 AM, Richard Biener wrote:
> >
> > On Tue, 19 Jul 2022, Qing Zhao wrote:
> >
> >> From
> GCC fails to bootstrap when configured with --enable-languages=all on
> machines that have older versions of GNAT installed as the system Ada
> compiler. In configure, it's not sufficient to check whether gnat is
> available, but whether a sufficiently recent version of GNAT is
> installed.
On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>
> > On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
> >
> > On Tue, 19 Jul 2022, Qing Zhao wrote:
> >
> >> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
> >> From: Qing Zhao
> >> Date: Mon, 18 Jul 2022 18:12:26 +
> >>
Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/7/25 13:11, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with
> three 64bit operands.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay
Even though ranger is type agnostic, SCEV seems to only work with
integers. This patch removes some FIXME notes making it explicit that
bounds_of_var_in_loop only works with iranges.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-fold.cc (fold_using_range::range_of_phi): Only
Make all vrange::supports_*_p methods const_tree as they can end up
being called from functions that are const_tree.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (vrange::supports_type_p): Use const_tree.
(irange::supports_type_p): Same.
These are some assorted cleanups to the frange class to make it easier
to drop in an implementation with FP endpoints:
* frange::set() had some asserts limiting the type of arguments
passed. There's no reason why we can't handle all the variants.
Worse comes to worse, we can always return a
41 matches
Mail list logo
