Hi Uros,
This patch fix Zhaoxin CPU Vendor ID detection problem
and add Zhaoxin "lujiazui" processor support and tuning.
Currently gcc can't recognize Zhaoxin CPU (Vendor ID "CentaurHauls" and
"Shanghai")
and wrongly identify Zhaoxin "lujiazui" as Intel core2 or i386, which is
confusing for
When building a const to a reg, it may need a few instructions.
This patch updates rs6000_rtx_costs to make it more accurate for
constant building.
With this patch, cse.cc could get accurate cost for complex
constant and then read the constant from a pool.
As discussed in the mail list, this
PR analyzer/104954 tracks that -fanalyzer was taking a very long time
on a particular source file in the Linux kernel:
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
One issue occurs with the repeated use of dynamic debug lines e.g. via
the DC_LOG_BANDWIDTH_CALCS macro, such as in
From: Avinash Sonawane
On Thu, 2022-03-24 at 10:41 +0530, Avinash Sonawane wrote:
> On Wed, 23 Mar 2022 18:33:38 -0400
> David Malcolm wrote:
>
> > This is almost ready to push to trunk, but there are a couple of
> > extra
> > tasks needed to be done:
>
> Done.
>
> Please find the attached
On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
> On 3/24/22 15:56, Marek Polacek wrote:
> > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> > > On 3/24/22 11:49, Marek Polacek wrote:
> > > > I started looking into this PR because in GCC 4.9 we were able to
> > > >
On 3/24/22 17:53, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression
On 3/13/22 19:43, Zhao Wei Liew wrote:
On Sat, 12 Mar 2022 at 06:15, Jason Merrill wrote:
It looks good, but unfortunately regresses some other warning tests,
such as Wnonnull5.C. Please remember to run the regression tests before
sending a patch (https://gcc.gnu.org/contribute.html#testing).
On 3/17/22 01:51, Zhao Wei Liew wrote:
Thanks for the review. I've tested and uploaded a new patch v2 with
the requested changes.
On Thu, 17 Mar 2022 at 09:20, Jason Merrill wrote:
On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
This patch adds a warning when casting "this" to
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
> On 3/18/22 17:55, Marek Polacek wrote:
> > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
> > > On 3/10/22 18:04, Marek Polacek wrote:
> > > > Since r9-6073 cxx_eval_store_expression preevaluates the value to
> > > >
On 3/24/22 15:56, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's
On 3/22/22 16:59, Marek Polacek via Gcc-patches wrote:
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
If two arrays do not have the exact same element type including qualification, this could
be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be distinguished
by the
On 3/23/22 21:01, Pokechu22 via Gcc-patches wrote:
When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> On 3/24/22 11:49, Marek Polacek wrote:
> > I started looking into this PR because in GCC 4.9 we were able to
> > detect the invalid
> >
> >struct alignas(void) S{};
> >
> > but I broke it in r210262.
> >
> > It's ill-formed
With the changes for PR81359 and PR88368 to make get_nsdmi errors be treated
as substitution failure, we have the problem that if we check
std::is_default_constructible for a complete class that still has unparsed
default member initializers, we get an answer (false) that will be wrong
once the
Ping.
On 16/03/2022 15:00, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
As requested, I updated the Neoverse N2 entry to use the
AARCH64_FL_FOR_ARCH9 feature set, removed duplicate entries, updated
the ARCH_INDENT to 9A and moved it under the Armv9 cores.
gcc/ChangeLog:
*
On 3/24/22 13:03, Marek Polacek wrote:
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
> On 3/23/22 19:26, Marek Polacek wrote:
> > On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
> > > On 3/22/22 19:55, Marek Polacek wrote:
> > > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
> >
On 3/21/22 12:55, Jørgen Kvalsvik via Gcc-patches wrote:
Hello.
Thanks for very interesting extension of the existing GCOV profiling.
I briefly read the patch and investigated what happens and I've got various
questions/comments about it:
1) Do I correctly understand that
On 3/24/22 11:49, Marek Polacek wrote:
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same effect as alignas(alignof(type-id))", and
On 3/18/22 17:55, Marek Polacek wrote:
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
On 3/24/22 10:32, Patrick Palka wrote:
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This change causes us to no longer diagnose ahead
On 3/23/22 19:26, Marek Polacek wrote:
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
On 3/22/22 19:55, Marek Polacek wrote:
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().
The history of
On Mon, 2022-03-14 at 18:38 +0100, David Seifert wrote:
> Use AC_CACHE_CHECK to store the result of the header check for
> systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
> AC_CACHE_CHECK(..., glibcxx_cv_sys_sdt_h).
>
> gcc/
> * configure.ac: Add AC_CACHE_CHECK(...,
Hi Guys,
Attached is a proposed patch to fix another Rust demangling bug
reported in PR 105039. I would like to say that this is the
last time that we will see this problem for the Rust demangler,
but I am not that naive...
OK to apply ?
Cheers
Nickdiff --git
Hi, Jakub:
Thanks for your review.
在 2022/3/24 下午8:41, Jakub Jelinek 写道:
On Thu, Mar 24, 2022 at 08:37:32PM +0800, chenglulu wrote:
libgomp/
* configure.tgt: Add LoongArch triplet.
Ok.
diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8
On Thu, Mar 24, 2022 at 08:37:32PM +0800, chenglulu wrote:
> libgomp/
>
> * configure.tgt: Add LoongArch triplet.
Ok.
> diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
> index d4f1e741b5a..2cd7272fcd8 100644
> --- a/libgomp/configure.tgt
> +++ b/libgomp/configure.tgt
> @@
* contrib/config-list.mk: Add LoongArch triplet.
* gcc/doc/install.texi: Add LoongArch options section.
* gcc/doc/invoke.texi: Add LoongArch options section.
* gcc/doc/md.texi: Add LoongArch options section.
---
contrib/config-list.mk | 4 +-
gcc/doc/install.texi
libgcc/
* config/loongarch/crtfastmath.c: New file.
* config/loongarch/linux-unwind.h: Like wise.
* config/loongarch/sfp-machine.h: Like wise.
* config/loongarch/t-crtstuff: Like wise.
* config/loongarch/t-loongarch: Like wise.
*
gcc/
* config/loongarch/larchintrin.h: New file.
* config/loongarch/loongarch-builtins.cc: New file.
---
gcc/config/loongarch/larchintrin.h | 355 +
gcc/config/loongarch/loongarch-builtins.cc | 424 +
2 files changed, 779 insertions(+)
gcc/testsuite/
* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
* gcc.dg/20020312-2.c: Add LoongArch support.
*
gcc/
* common/config/loongarch/loongarch-common.cc: New file.
* config/loongarch/genopts/genstr.sh: New file.
* config/loongarch/genopts/loongarch-strings: New file.
* config/loongarch/genopts/loongarch.opt.in: New file.
* config/loongarch/loongarch-str.h:
libgcc/
* configure: Regenerate file.
---
libgcc/configure | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libgcc/configure b/libgcc/configure
index 52bf25d4e94..1f9b2ac578b 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -2403,6 +2403,9 @@ case "${host}"
gcc/
* config/loongarch/loongarch-c.cc
---
gcc/config/loongarch/loongarch-c.cc | 109
1 file changed, 109 insertions(+)
create mode 100644 gcc/config/loongarch/loongarch-c.cc
diff --git a/gcc/config/loongarch/loongarch-c.cc
gcc/
* configure: Regenerate file.
---
gcc/configure | 66 ++-
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index 14b19c8fe0c..1c1195e95cb 100755
--- a/gcc/configure
+++ b/gcc/configure
@@
libgomp/
* configure.tgt: Add LoongArch triplet.
---
libgomp/configure.tgt | 4
1 file changed, 4 insertions(+)
diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
@@ -56,6 +56,10
* config/picflag.m4: Default add build option '-fpic' for LoongArch.
* configure: Add LoongArch tuples.
* configure.ac: Like wise.
---
config/picflag.m4 | 3 +++
configure | 10 +-
configure.ac | 10 +-
3 files changed, 21 insertions(+), 2
Hi, all:
This is the v10 version of LoongArch Port based on
d1ca63a1b7d5986913b14567a4950b055a5a3f07.
Please review.
We know it is stage4, I think it is ok for a new prot.
The kernel side upstream waiting for a approval by gcc side,
if it is blocked by stage4, a approval for GCC13 will be
On Thu, Mar 24, 2022 at 01:08:56PM +0100, Tom de Vries wrote:
> Ack, updated patch, added missing changelog contribution.
>
> OK for trunk?
Yes. I guess it is a backport candidate to release branches as well
(after a while).
Jakub
On 3/24/22 11:59, Jakub Jelinek wrote:
On Thu, Mar 24, 2022 at 11:01:30AM +0100, Tom de Vries wrote:
Shouldn't that be instead
return (woldval & ((UWORD) -1 << shift)) != 0;
or
return (woldval & ((UWORD) ~(UWORD) 0 << shift)) != 0;
?
Well, I used '(woldval & wval) == wval' based on
On 3/24/22 11:34, Sebastian Huber wrote:
The gcov_profile_merge() already had code to deal with profile information
which had no counterpart to merge with. For profile information from files
with no associated counterpart, the profile information is simply used as is
with the weighting
On 3/24/22 11:51, Sebastian Huber wrote:
Maybe we could add the file path into the gcov information stream using a new
tag:
#define GCOV_TAG_GCDA_FILE_NAME ((gcov_unsigned_t)0xa500)
Then the complete gcov information can be dumped using a single base64 encoded
stream. We could add some
On Thu, Mar 24, 2022 at 11:01:30AM +0100, Tom de Vries wrote:
> > Shouldn't that be instead
> >return (woldval & ((UWORD) -1 << shift)) != 0;
> > or
> >return (woldval & ((UWORD) ~(UWORD) 0 << shift)) != 0;
> > ?
>
> Well, I used '(woldval & wval) == wval' based on the fact that the set
>
On 24/03/2022 11:29, Martin Liška wrote:
On 3/23/22 15:50, Sebastian Huber wrote:
The attached script reads the log file and creates the *.gcda files
using gcov-tool. Initially, the target files do not exist.
Now I've got your use-case and I like it. It's cool one can utilize GCOV
even
On Thu, 24 Mar 2022, Jakub Jelinek wrote:
> On Tue, Mar 22, 2022 at 05:51:58PM +0100, Jakub Jelinek via Gcc wrote:
> > I guess it would be nice to include the testcases we are talking about,
> > like { float x; int : 0; float y; } and { float x; int : 0; } and
> > { int : 0; float x; } into
On Tue, Mar 22, 2022 at 05:51:58PM +0100, Jakub Jelinek via Gcc wrote:
> I guess it would be nice to include the testcases we are talking about,
> like { float x; int : 0; float y; } and { float x; int : 0; } and
> { int : 0; float x; } into compat.exp testsuite so that we see ABI
> differences in
This is a regression present on mainline, 11 and 10 branches. When the serial
port is closed, we need to ensure that the port handle is properly reset for
it to be detected as closed.
Tested on x86-64/Linux, applied on mainline, 11 and 10 branches.
2022-03-24 Pascal Obry
PR
The gcov_profile_merge() already had code to deal with profile information
which had no counterpart to merge with. For profile information from files
with no associated counterpart, the profile information is simply used as is
with the weighting transformation applied. Make sure that
On 3/23/22 15:50, Sebastian Huber wrote:
The attached script reads the log file and creates the *.gcda files using
gcov-tool. Initially, the target files do not exist.
Now I've got your use-case and I like it. It's cool one can utilize GCOV even
without a filesystem.
Please update the
PING^2
On 3/4/22 14:47, Martin Liška wrote:
PING^1
On 1/26/22 12:11, Martin Liška wrote:
Hello.
Right now, switch lowering does not update basic_block::count values
so that they are uninitiliazed. Moreover, I've updated probability scaling
when a more complex expansion happens. There are
When changing the predcom pass to use auto_vec leaks were introduced by
failing to replace deallocation with C++ delete. The following does
this. It also fixes leaks in vectorization and range folding.
Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-03-24 Richard Biener
On Thu, 24 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, operand_equal_p already contains some hacks so that
> it can be called already on pre-instantiation C++ trees from templates,
> but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
> case broke this.
On 3/24/22 10:02, Jakub Jelinek wrote:
On Thu, Mar 24, 2022 at 09:28:15AM +0100, Tom de Vries via Gcc-patches wrote:
Hi,
On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
...
FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
...
which mimimized to:
...
#include
Hi!
As mentioned in the PR, operand_equal_p already contains some hacks so that
it can be called already on pre-instantiation C++ trees from templates,
but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
case broke this. Many such COMPONENT_REFs are already punted on earlier
On Thu, Mar 24, 2022 at 09:28:15AM +0100, Tom de Vries via Gcc-patches wrote:
> Hi,
>
> On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
> ...
> FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
> ...
> which mimimized to:
> ...
> #include
> atomic_flag a =
Hi,
On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
...
FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
...
which mimimized to:
...
#include
atomic_flag a = ATOMIC_FLAG_INIT;
int main () {
if ((atomic_flag_test_and_set) ())
__builtin_abort ();
On Thu, Mar 24, 2022 at 08:39:44AM +0530, Siddhesh Poyarekar wrote:
> Limit object size computation only to the simple case where access
> attribute has been explicitly specified. The object passed to
> __builtin_dynamic_object_size could either be a pointer or a VLA whose
> size has been
On Thu, Mar 24, 2022 at 5:06 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> The copies of identifiers, indended to associate hardening SSA
> temporaries to the original variables they refer to, end up causing
> -fcompare-debug to fail, because DECL_UIDs are not identical, and the
> nouid flag
On Thu, Mar 24, 2022 at 2:43 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> If we harden a compare at the end of a block with an edge to the
> abnormal dispatch block, it won't have a single successor. Arrange to
> split the block at its final stmt so as to have a single succ.
>
> Regstrapped
60 matches
Mail list logo
