https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
--- Comment #4 from Aldy Hernandez ---
This is an issue with the TRUNC_DIV_EXPR range-op entry optimizing divisions by
powers of 2 into right shifts. We're right shifting the mask by the shift
amount.
operator_div::fold_range():
...
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #11 from Rama Malladi ---
(In reply to Wilco from comment #10)
> I'm seeing about 1.5% gain on Neoverse V1 and 0.5% loss on Neoverse N1. I'll
> post a patch that allows per-CPU settings for FMA reassociation, so you'll
> get good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #6 from Andrew Pinski ---
(In reply to Marc Glisse from comment #5)
> typedef signed char v16qs __attribute__((vector_size(16)));
> auto bar(v16qs x) { return x < 48; }
>
> clang does expand it as 48 gt x. Gcc however does its
> -Original Message-
> From: Richard Biener
> Sent: Saturday, November 5, 2022 11:33 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions from
> bitfields and array_refs
>
> On Mon, Oct 31, 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #5 from Marc Glisse ---
typedef signed char v16qs __attribute__((vector_size(16)));
auto bar(v16qs x) { return x < 48; }
clang does expand it as 48 gt x. Gcc however does its usual change to x <= 47,
which it then tries to expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #4 from Hongtao.liu ---
> even. Notice the < vs <= there.
> I suspect the <= expansion part of the x86_64 backend needs to be fixed up
> to produce better code.
Hmm, we do have a extra pcmpeq to negate the result.
在 2022/11/7 15:03, Andrew Pinski 写道:
The win32 thread model does not have `std::mutex`; but there is no
`pthread_mutex_t` either, so it
does not build either way.
Oh, but I would assume it will later on right?
There has been effort on C++11 threading support for win32 thread model, but I
在 2022/11/7 15:03, Andrew Pinski 写道:
The win32 thread model does not have `std::mutex`; but there is no
`pthread_mutex_t` either, so it
does not build either way.
Oh, but I would assume it will later on right?
There has been effort on C++11 threading support for win32 thread model, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #3 from Hongtao.liu ---
Failed to match this instruction:
(set (reg:V16QI 95)
(eq:V16QI (gt:V16QI (subreg:V16QI (reg:V2DI 89 [ MEM[(const __m128i_u *
{ref-all})p_2(D)] ]) 0)
(mem/u/c:V16QI (symbol_ref/u:DI ("*.LC0")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target|x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
On Sun, Nov 6, 2022 at 10:51 PM LIU Hao wrote:
>
> 在 2022-11-07 12:37, Andrew Pinski 写道:
> >
> > The original code which used pthread was added in GCC 5 way before GCC
> > moved to being written in C++11 which was only in the last 3 years.
> > pthread_* functions were the best choice at the time
On Sun, Nov 6, 2022 at 10:51 PM LIU Hao wrote:
>
> 在 2022-11-07 12:37, Andrew Pinski 写道:
> >
> > The original code which used pthread was added in GCC 5 way before GCC
> > moved to being written in C++11 which was only in the last 3 years.
> > pthread_* functions were the best choice at the time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107536
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Summary|[12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107535
Richard Biener changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
Andrew Pinski changed:
What|Removed |Added
Summary|simd, redundant pcmpeqb and |[10/11/12/13 Regression]
6QI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
(expr_list:REG_EQUAL (const_vector:V16QI [
(const_int 47 [0x2f]) repeated x16
])
在 2022-11-07 12:37, Andrew Pinski 写道:
The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason
在 2022-11-07 12:37, Andrew Pinski 写道:
The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI. So these instructions can be generated in a 32-bit environment. The patch
removes TARGET_64BIT check for these instructiions.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
Bug ID: 107546
Summary: simd, redundant pcmpeqb and pxor
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105261
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.2
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107545
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
On Sun, Nov 6, 2022 at 7:59 PM LIU Hao via Gcc wrote:
>
> Greetings,
>
> At the moment, there are references to pthread mutexes in
> 'gcc/jit/libgccjit.cc' and
> 'gcc/git/jit-playback.cc'. The former was introduced by
> 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in
> 2020, while the latter was
Greetings,
At the moment, there are references to pthread mutexes in 'gcc/jit/libgccjit.cc' and
'gcc/git/jit-playback.cc'. The former was introduced by 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in
2020, while the latter was introduced by 38771e4e1fdacfbdac5a14e50fcc0538577b1bdb in 2014.
Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107545
Bug ID: 107545
Summary: __is_abstract intrinsic fails to compile on incomplete
unions
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
On Mon, Nov 7, 2022 at 9:41 AM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/i386-common.cc
> (processor_names): Add grandridge.
> (processor_alias_table): Ditto.
> * common/config/i386/i386-cpuinfo.h:
> (enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540
--- Comment #2 from Hongtao.liu ---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fa93ae7bf21..4e8463addc3 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -12203,7 +12203,7 @@ (define_insn
gcc/ChangeLog:
* config/i386/i386-options.cc (m_CORE_ATOM): New.
* config/i386/x86-tune.def
(X86_TUNE_SCHEDULE): Initial tune for CORE_ATOM.
(X86_TUNE_PARTIAL_REG_DEPENDENCY): Ditto.
(X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY): Ditto.
gcc/ChangeLog:
* common/config/i386/i386-common.cc
(processor_names): Add grandridge.
(processor_alias_table): Ditto.
* common/config/i386/i386-cpuinfo.h:
(enum processor_types): Add INTEL_GRANDRIDGE.
* config.gcc: Add -march=grandridge.
*
Hi all,
These patches aimed to add initial Granite Rapids support for GCC.
Also we added a new m_CORE_ATOM for future atom core tune. They need
to be checked in after RAO-INT patch.
The information for Granite Rapids comes following:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1
On Sun, Nov 6, 2022 at 8:56 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
> The patches aimed to add Intel RAO-INT.
>
> The information is based on newly released
> Intel Architecture Instruction Set Extensions and Future Features.
>
> The document comes following:
>
On Sun, Nov 6, 2022 at 9:00 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi
>
> The patch is to add flag -mprefer-remote-atomic to control whether to
> generate raoint insn for atomic operations.
> Ok for trunk?
Ok with below 2 little adjustments.
>
> BRs,
> Lingling
>
> gcc/ChangeLog:
>
>
On Fri, Nov 4, 2022 at 3:47 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> We will take back the patches which add a new parameter on original
> builtin_prefetch and implement instruction prefetch on that.
>
> Also we consider that since we will only do that on specific backend,
> no
On Fri, Nov 4, 2022 at 4:14 PM Haochen Jiang via Gcc-patches
wrote:
>
> From: "Hu, Lin1"
>
> Hi all,
>
> This patch aimed to add initial Granite Rapids support for GCC.
> It needs to be checked in after prefetchit0/t1 patch.
>
> The information for Granite Rapids comes following:
>
Snapshot gcc-13-20221106 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20221106/
and on various mirrors, see http://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
Hello,
On 06.11.22 21:32, Mikael Morin wrote:
Le 05/11/2022 à 23:28, Tobias Burnus a écrit :
OK for mainline?
The trans-array.c part looks good.
A couple of nits for the trans-expr.cc part:
- /* Use the rhs string length and the lhs element size. */
- size = string_length;
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544
--- Comment #4 from danakj at orodu dot net ---
It looks related but I am not sure it is a duplicate. In this case, the concept
is being used from a non-friend context first and still accessing the private
data. In that bug, they demonstrate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
--- Comment #3 from Franck Behaghel
---
Not sure that would help but disabling those pair of passes :
-fdisable-tree-ccp3 -fdisable-tree-ccp4
or -fdisable-tree-ccp4 -fdisable-tree-dom2
or -fdisable-tree-dom2 -fdisable-tree-dom3
removes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544
--- Comment #1 from danakj at orodu dot net ---
Clang report: https://github.com/llvm/llvm-project/issues/58833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544
Bug ID: 107544
Summary: Friended struct with concept gives different output in
clang/gcc/MSVC
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107543
Bug ID: 107543
Summary: c-family/c-cppbuiltin.cc: Undefine
__GNUC_STDC_INLINE__ in C++ mode?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
--- Comment #3 from danakj at orodu dot net ---
> Note please next time also attach the testcase (or put it inline) and not
> just link against godbolt.
Will do, thanks for attaching it for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
--- Comment #2 from danakj at orodu dot net ---
The same thing works okay with operator== instead of operator<=>
https://godbolt.org/z/qnPx3bYT4
```
#include
#include
template
concept Ord = requires(const Lhs& lhs, const Rhs& rhs) {
{
Hello,
Le 05/11/2022 à 23:28, Tobias Burnus a écrit :
Prior to the attached patch, there is a problem with realloc on assignment
with kind=4 characters as the string length was compared with the byte
size,
which was always true.
(...)
OK for mainline?
The trans-array.c part looks good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
--- Comment #1 from Andrew Pinski ---
Created attachment 53840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53840=edit
testcase
Note please next time also attach the testcase (or put it inline) and not just
link against godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542
Bug ID: 107542
Summary: ICE in spaceship_comp_cat, at cp/method.cc:1055
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Sat, Nov 5, 2022 at 12:25 PM Richard Biener
wrote:
>
> On Wed, Nov 2, 2022 at 1:46 PM Uros Bizjak wrote:
> >
> > On Wed, Nov 2, 2022 at 1:45 PM Robin Dapp wrote:
> > >
> > > > IIRC, I was trying to "fix" modeless operand by giving it a mode, but
> > > > since it made no difference for x86, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Franck Behaghel changed:
What|Removed |Added
CC||franckbehaghel_gcc@protonma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95797
Andrew Pinski changed:
What|Removed |Added
CC||src at andyf dot de
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98052
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4e4e3ffd10f53ef71696bc728ab40258751a2df4
commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4e4e3ffd10f53ef71696bc728ab40258751a2df4
commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #18 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4e4e3ffd10f53ef71696bc728ab40258751a2df4
commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka
Date:
After Jakub and Richi's suggestion of using the same representation
for tracking known bits as we do in CCP, I took a peek at the code and
realized there's a plethora of bit-tracking code there that we could
be sharing with range-ops. For example, the multiplication
optimizations are way better
Hi
The patch is to add flag -mprefer-remote-atomic to control whether to generate
raoint insn for atomic operations.
Ok for trunk?
BRs,
Lingling
gcc/ChangeLog:
* config/i386/i386.opt:Add -mprefer-remote-atomic.
* config/i386/sync.md (atomic_):
New define_expand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Bug ID: 107541
Summary: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi,
The patches aimed to add Intel RAO-INT.
The information is based on newly released
Intel Architecture Instruction Set Extensions and Future Features.
The document comes following:
From: Ju-Zhe Zhong
This patch support RVV scalable register spilling.
prologue && epilogue handling pick up prototype from Monk Chiang
.
Co-authored-by: Monk Chiang
gcc/ChangeLog:
* config/riscv/riscv-v.cc (emit_pred_move): Adjust for scalable
register spilling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540
Bug ID: 107540
Summary: [13 Regression] ICE: SIGSEGV in
memory_operand(rtx_def*, machine_mode) (recog.cc:1834)
with -flive-range-shrinkage
Product: gcc
Version:
On Sun, 2022-11-06 at 09:46 +0800, Lulu Cheng wrote:
> I think it should be here:
>
> if (!increment && !decrement)
> continue;
>
> + if ((increment && rhs == HOST_WIDE_INT_MAX)
> + || (decrement && rhs == HOST_WIDE_INT_MIN))
> +
Perhaps rvv.exp should add -I. so that the wrapper is found regardless?
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
--- Comment #3 from Andrew Pinski ---
Created attachment 53837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53837=edit
reduced further
Here is even more reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
--- Comment #2 from Andrew Pinski ---
Note the ICE only shows up with checking enabled. It is definitely a bug but
one which most users won't see.
74 matches
Mail list logo
