Hi all,
AVX10 has been published for one and half year and we have got many feedbacks
on that, one of the feedback is on whether the alias option -mavx10.x should
point to 256 or 512.
If you also pay attention to LLVM community, you might see this thread related
to AVX10 options just sent out sev
Thanks Jeff, I will resolve the conflict and send v3 after test.
Pan
-Original Message-
From: Jeff Law
Sent: Monday, January 27, 2025 12:38 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v2 1/4] RISC-V: R
> It's a nice cleanup, but let's defer since it doesn't fix a bug.
Sure thing, will defer to gcc-16.
Pan
-Original Message-
From: Jeff Law
Sent: Sunday, January 26, 2025 9:34 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com;
On 1/26/25 2:07 PM, Harald Anlauf wrote:
Dear all,
in the checking of imported interfaces we need to use the local names
of procedures that are renamed-on-use, as the original name becomes
inaccessible. Similarly, we should not compare interfaces of
non-bind(C) procedures against bind(C) interf
Hi Sandra,
this patch LGTM with some minor comments. Or rather:
I have a few minor comments that should be fixed right away
and a few larger items for which PRs should be filed.
See below.
Sandra Loosemore wrote:
gcc/fortran/ChangeLog
PR middle-end/112779
PR middle-end/113904
This was seemingly forgotten when UNROLL/TILE was added.
Committed asr15-7220-g7cd133a6e4b042 as obvious. Tobias
commit 7cd133a6e4b04262620489dbf4b4e3ae5e96c95f
Author: Tobias Burnus
Date: Mon Jan 27 00:35:17 2025 +0100
Fortran: In openmp.cc, uncomment unroll/tile lines of gfc_omp_directi
Dear all,
in the checking of imported interfaces we need to use the local names
of procedures that are renamed-on-use, as the original name becomes
inaccessible. Similarly, we should not compare interfaces of
non-bind(C) procedures against bind(C) interfaces that are not
explicitly made accessib
"Maciej W. Rozycki" writes:
...
> There are notable regressions between a plain `-mno-bwx' configuration
> and a `-mno-bwx -msafe-partial' one:
>
> FAIL: gm2/iso/run/pass/strcons.mod execution, -g
> FAIL: gm2/iso/run/pass/strcons.mod execution, -O
> FAIL: gm2/iso/run/pass/strcons.mod executi
On Sat, Jan 25, 2025 at 10:53:50AM -0500, Jason Merrill wrote:
> On 1/25/25 4:12 AM, Jakub Jelinek wrote:
> > On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
> > > Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
> > > the error case we're failing anyway; in
On Sun, Jan 26, 2025 at 08:35:29AM -0700, Jeff Law wrote:
> On 1/23/25 8:49 AM, Stefan Schulze Frielinghaus wrote:
> > On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
> > [...]
> > > > > Do we detect conflicts between a hard register constraint and another
> > > > > constraint which requi
On 1/23/25 12:01 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to fix the wroing code generation for the scalar
signed SAT_SUB. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in sca
On 1/23/25 12:01 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to fix the wroing code generation for the scalar
signed SAT_ADD. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in sca
On 1/23/25 12:01 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to refactor the helper function of the SAT_*
scalar. The helper function will convert the define_pattern ops
to the xmode reg for the underlying code-gen. This patch add
new parameter for ZERO_EXTEND or SIGN_E
gcc/fortran/ChangeLog
* openmp.cc (resolve_omp_atomic): Fix typo in error message.
gcc/testsuite/ChangeLog
* gfortran.dg/gomp/atomic-26.f90: Correct expected output after
fixing typo in error message.
---
gcc/fortran/openmp.cc| 2 +-
gcc/testsuite/g
On 1/23/25 8:49 AM, Stefan Schulze Frielinghaus wrote:
On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
[...]
Do we detect conflicts between a hard register constraint and another
constraint which requires a singleton class? That's going to be an error I
suspect, but curious if it's
On 1/26/25 6:33 AM, pan2...@intel.com wrote:
From: Pan Li
After we add the frm register to the global_regs, we may not need to
define_insn that volatile to emit the frm restore insns. The
cooperatively-managed global register will help to handle this, instead
of emit the volatile define_ins
On 1/24/25 3:57 AM, Robin Dapp wrote:
So this isn't a regression, but I can also understand the desire to fix
this fairly significant performance issue.
I'd argue it is a regression as the match.pd pattern that merges the permutes
was introduces after GCC 14.
Good point. I hadn't thought ab
From: Pan Li
After we add the frm register to the global_regs, we may not need to
define_insn that volatile to emit the frm restore insns. The
cooperatively-managed global register will help to handle this, instead
of emit the volatile define_insn explicitly.
gcc/ChangeLog:
* config/ri
On 1/24/25 3:12 PM, Vineet Gupta wrote:
RV-Vector FP-INT insns use the rounding mode in FRM register which if
explicitly set for V insn needs, is saved/restored (although from the
psABI CC Spec, it is not clear if it actually a caller-saved or
callee-saved).
Anyhow in the failure case the sav
Formatting a time point with %c was implemented by calling
std::vprint_to with format string constructed from locale's D_T_FMT
string, but in some locales this string does not compliant to
chrono-specs. So just use _M_locale_fmt to avoid this problem.
libstdc++-v3/ChangeLog:
PR libstdc++/
20 matches
Mail list logo
