Sent from my iPhone
On 12/23/23 17:49, Roger Sayle wrote:
Hi YunQiang (and Jeff),
MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) ==
true based on that the hard register is always sign-extended, but
here the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS
On 12/23/23 15:46, YunQiang Su wrote:
Jeff Law 于2023年12月24日周日 00:51写道：
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125
Bug ID: 113125
Summary: [D] internal compiler error: in make_import, at
d/imports.cc:48
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Thanks Jeff for comments.
> Isn't this going to XPASS for non-vector configurations?
Yes, I think we still need something like riscv_v here.
> If I understand correctly, the test requires loop unrolling and its
> associated variable expansion to trigger the desired behavior. VLA
> style
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, December 23, 2023 11:38 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com; richard.guent...@gmail.com; tamar.christ...@arm.com
Subject: Re: [PATCH v2]
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Is there a specific reason thy -fc-prototypes (Interoperability
Options section) is excluded from manpage?
Regards,
Rimvydas
From 3adb6cd8a2aa1576a8ff63b280239e725f1f112e Mon Sep 17 00:00:00 2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #13 from Jiu Fu Guo ---
(In reply to GCC Commits from comment #9)
> The master branch has been updated by Hans-Peter Nilsson :
>
> https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #11 from Hans-Peter Nilsson ---
(In reply to Jiu Fu Guo from comment #8)
> I'm wondering if we need to revert r14-6674 to avoid this functionality
> issue. And revisit/enhance the patch later.
No need, not anymore; not because of
> There's a PR in Bugzilla around this representational issue on MIPS, but I
can't find
> it straight away.
Found it. It's PR rtl-optimization/104914, where we've already
discussed this in comments #15 and #16.
> -Original Message-
> From: Roger Sayle
> Sent: 24 December 2023 00:50
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #10 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #6)
> So I did a quick audit of the EH_RETURN_HANDLER_RTX
Yeah, me too.
> and most are registers
> rather than a memory location . And the ones which were
Hi YunQiang (and Jeff),
> MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> based on that the hard register is always sign-extended, but here
> the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS backend shouldn't be returning
true
No test-case, but the regress-367 from r14-6674-g4759383245ac97 is
"back" to regress-10 for cris-elf+cris-sim with this patch applied
to gcc from that revision.
Also, I wonder why none of those other targets with a MEM for
EH_RETURN_HANDLER_RTX with an address relative to
frame_pointer_rtx (as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #9 from GCC Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #8 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #6)
> So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers
> rather than a memory location . And the ones which were memory locations
> used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #7 from Jiu Fu Guo ---
(In reply to Hans-Peter Nilsson from comment #3)
>
> I'm "guessing" that the problem with the patch, is that anything any port
> stores through a pointer based on virtual_incoming_args_rtx before
> returning,
One of the cool features of the H8 backend is its use of tables to select
optimal shift implementations for different CPU variants. This patch
borrows (plagiarizes) that idiom for SImode left shifts in the ARC backend
(for CPUs without a barrel-shifter). This provides a convenient mechanism
for
This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin
in the type_traits header for traits that have a corresponding fallback
non-built-in implementation. This macro supports to toggle the use of
built-in traits in the type_traits header through
I suggest you send the first patch which support theadvector with only adding
"th.".
After it's done, then we can talk about it later.
juzhe.zh...@rivai.ai
发件人： joshua
发送时间： 2023-12-23 11:37
收件人： juzhe.zh...@rivai.ai; gcc-patches
抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw;
Jeff Law 于2023年12月24日周日 00:51写道：
>
>
>
> On 12/23/23 01:58, YunQiang Su wrote:
> > On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> > if 31 or above bits is polluted by an bitops, we will need an
> > truncate. Let's emit one, and mark let's use the same hardreg
> > as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #5 from Desmond Gold ---
when I mentioned being "inspired by," I was referring to drawing guidance from
existing reference implementations like libc++, STL, and Kokkos for the
implementation in libstdc++. Specifically, for how they
Snapshot gcc-13-20231223 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20231223/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
This patch optimizes the compilation performance of
std::is_unbounded_array by dispatching to the new
__is_unbounded_array built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_unbounded_array_v): Use
__is_unbounded_array built-in trait.
Signed-off-by: Ken Matsui
This patch implements built-in trait for std::is_unbounded_array.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc (trait_expr_value): Likewise.
This patch implements built-in trait for std::is_pointer.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
This patch optimizes the compilation performance of std::is_pointer
by dispatching to the new __is_pointer built-in trait.
libstdc++-v3/ChangeLog:
* include/bits/cpp_type_traits.h (__is_pointer): Use
__is_pointer built-in trait. Optimize its implementation.
*
This patch optimizes the compilation performance of std::is_volatile
by dispatching to the new __is_volatile built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_volatile): Use __is_volatile
built-in trait.
(is_volatile_v): Likewise.
Signed-off-by: Ken
This patch implements built-in trait for std::is_volatile.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
This patch optimizes the compilation performance of std::is_const
by dispatching to the new __is_const built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_const): Use __is_const built-in
trait.
(is_const_v): Likewise.
Signed-off-by: Ken Matsui
---
This patch implements built-in trait for std::is_const.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
This patch series implements __is_const, __is_volatile, __is_pointer,
and __is_unbounded_array built-in traits, which were isolated from my
previous patch series "Optimize type traits compilation performance"
because they contained performance regression. I confirmed that this
patch series does
/* sprintf()関数 */
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
/* if (output_len >= 80)
{
fprintf(stderr, "Output
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
On Sat, Dec 23, 2023 at 1:36 PM Ken Matsui wrote:
>
> This patch implements built-in trait for std::is_const.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_const.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
> * semantics.cc (trait_expr_value):
This patch optimizes the compilation performance of std::is_const
by dispatching to the new __is_const built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_const): Use __is_const built-in
trait.
(is_const_v): Likewise.
Signed-off-by: Ken Matsui
---
This patch implements built-in trait for std::is_const.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
This patch series implements __is_const, __is_volatile, __is_pointer,
and __is_unbounded_array built-in traits, which were isolated from my
previous patch series "Optimize type traits compilation performance"
because they contained performance regression. I confirmed that this
patch series does
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory
about how to merge these?
Why isn't push_abi_namespace doing the right setup here? (and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
Like r14-2293-g11350734240dba and r14-2289-gb083203f053f16,
reassociation can combine across a few bb and one of the usage
can be an uninitializated variable and if going from an conditional
usage to an unconditional usage can cause wrong code.
This uses maybe_undef_p like other passes where this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #4 from Andrew Pinski ---
When you say C structures here you mean the standard layout types (or the C++98
older definition of PODs)? Or do you mean structure types which has no member
functions/constructors at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #6 from Andrew Pinski ---
So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers
rather than a memory location . And the ones which were memory locations used
either frame or stack pointer directly which seemed
On 12/23/23 04:07, pan2...@intel.com wrote:
From: Pan Li
This patch would like to XFAIL the test case pr30957-1.c for the RVV when
build the elf with some configurations (list at the end of the log)
It will be vectorized during vect_transform_loop with a variable factor.
It won't benefit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #4)
> Hmm, see PR 32398 and PR 32769. PR 32769 is interesting because it was
> caused by the merge of the df branch where the store was being removed just
> like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #3 from Andrew Pinski ---
Is this a reasonable extension maybe. But this is an extension to the language
after all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
On Sun, 2023-12-24 at 00:56 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> > Hi,
> >
> > This patch will cause the following tests to fail:
> >
> > +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler error: in extract_insn,
> > at recog.cc:2812)
> > +FAIL:
On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> Hi,
>
> This patch will cause the following tests to fail:
>
> +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler error: in extract_insn, at
> recog.cc:2812)
> +FAIL: gcc.dg/vect/pr97081-2.c (test for excess errors)
> +FAIL:
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #2 from Alexey Dobriyan ---
this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081
but I don't care about the warning, only about error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #1 from Alexey Dobriyan ---
This is getting lengthy:
Please allow C99 semantics for "simple enough" stuff (read: C structs):
* allow reordering
* allow duplicating (possibly with warning),
* allow holes in the middle of arrays (1-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Bug ID: 113124
Summary: g++ should relax designated initialiser rules for
trivial classes (read: C structures) and C arrays.
Product: gcc
Version: 13.2.1
Status:
On 12/23/23 05:39, pan2...@intel.com wrote:
From: Pan Li
This patch would like to XFail the signbit-5 run test case for
the RVV. Given the case has one limitation like "This test does not
work when the truth type does not match vector type." in the beginning
of the test file. Aka, the RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #4 from Jonathan Wakely ---
What does "inspired by" mean? We need to be careful of authorship, copyright
ownership, and licensing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883
--- Comment #2 from John David Anglin ---
The excess errors differ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
Desmond Gold changed:
What|Removed |Added
CC||cooky.ykooc922 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113123
Bug ID: 113123
Summary: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
From: Pan Li
This patch would like to XFail the signbit-5 run test case for
the RVV. Given the case has one limitation like "This test does not
work when the truth type does not match vector type." in the beginning
of the test file. Aka, the RVV vector truth type is not integer type.
The
From: Pan Li
This patch would like to XFAIL the test case pr30957-1.c for the RVV when
build the elf with some configurations (list at the end of the log)
It will be vectorized during vect_transform_loop with a variable factor.
It won't benefit from unrolling/peeling and mark the loop->unroll as
Thanks all for comments, will have a try for riscv_v and send V2 if everything
goes well.
Pan
From: 钟居哲
Sent: Friday, December 22, 2023 6:44 AM
To: Jeff Law ; Li, Pan2 ; gcc-patches
Cc: Wang, Yanzhang ; kito.cheng
; richard.guenther ; Tamar
Christina
Subject: Re: Re: [PATCH v1] RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113122
Bug ID: 113122
Summary: Assembler messages: Error: operand type mismatch for
`movabs' / bad expression / invalid use of register
with -fprofile -mcmodel=large -masm=intel
On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > > The performance drop has nothing to do with this patch. I found that the
> > > h264 performance compiled
> > > by r14-6787 compared to r14-6421 dropped by 6.4%.
>
> Then I guess we
On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > The performance drop has nothing to do with this patch. I found that the
> > h264 performance compiled
> > by r14-6787 compared to r14-6421 dropped by 6.4%.
Then I guess we should create a bug report...
> But there is a problem. My
On Fri, 22 Dec 2023, 22:04 Andrew Pinski via Gcc, wrote:
> On Fri, Dec 22, 2023 at 1:54 PM Olavi Esker via Gcc
> wrote:
> >
> > Hello,
> >
> > #include
> > #include
> >
> > int main()
> > {
> > std::int8_t myInt{65};
> > myInt += 1;
> > std::cout << myInt;
> > }
> >
> > Guess what this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113105
--- Comment #5 from XChy ---
(In reply to Jakub Jelinek from comment #4)
> So, e.g. on x86_64,
> unsigned int
> f1 (unsigned val)
> {
> return val / 10 * 16 + val % 10;
> }
>
> unsigned int
> f2 (unsigned val)
> {
> return val / 10 * 6 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113071
XChy changed:
What|Removed |Added
CC||xxs_chy at outlook dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113119
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #4 from andysem at mail dot ru ---
> It's mostly OK to mix code with -frtti and -fno-rtti, but sometimes it bites
> you.
Note that in this case, it is the standard library that is built with -frtti
and the rest of the code is built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #3 from andysem at mail dot ru ---
I think, a failing dynamic_cast would not be useful as this would make
std::use_facet unusable with -fno-rtti.
Re. ODR violation in the latest code, while it is true that the
dynamic/static_cast is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121
Bug ID: 113121
Summary: failed to load pendings for
‘std::__format::__do_vformat_to’
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Hi!
On 2023-12-21T13:58:23+0100, Jakub Jelinek wrote:
> On Thu, Dec 21, 2023 at 01:31:19PM +0100, Thomas Schwinge wrote:
>> [...] the gimplification-level code re
>> 'Static locals [...] need to be "omp declare target"' runs *after*
>> 'omp_discover_implicit_declare_target'. Thus my "move" idea
On Dez 23 2023, YunQiang Su wrote:
> diff --git a/gcc/config/mips/driver-native.cc
> b/gcc/config/mips/driver-native.cc
> index afc276f5278..4ef48e14916 100644
> --- a/gcc/config/mips/driver-native.cc
> +++ b/gcc/config/mips/driver-native.cc
> @@ -44,6 +44,8 @@ const char *
>
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set (subreg/s/u:SI (reg/v:DI 200 [ val ]) 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:63df799074351e9b3ab90f5b3031ba2691385af8
commit r13-8175-g63df799074351e9b3ab90f5b3031ba2691385af8
Author: YunQiang Su
Users may wish just use -mtune=native for performance tuning only.
Let's don't make trouble for its case.
gcc/
* config/mips/driver-native.cc (host_detect_local_cpu):
don't add nan2008 option for -mtune=native.
---
gcc/config/mips/driver-native.cc | 3 ++-
1 file changed, 2
The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.
Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #7 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:384dbb0b4e751e6eb7ba3f9993a6cce466743926
commit r14-6811-g384dbb0b4e751e6eb7ba3f9993a6cce466743926
Author: YunQiang Su
Date: Tue
Jakub Jelinek 于2023年12月19日周二 16:40写道：
>
> On Tue, Dec 19, 2023 at 09:30:49AM +0800, YunQiang Su wrote:
> > The function `reconcat` cannot append string(s) to NULL,
> > as the concat process will stop at the first NULL.
> >
> > Let's always put the `ret` to the end, as it may be NULL.
> > We keep
81 matches
Mail list logo
