Hi All,
The attached fixes a problem that, judging by the comments, has been looked
at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placeme
On 4/15/24 10:03 PM, Alexandre Oliva wrote:
On Mar 29, 2024, Alexandre Oliva wrote:
On Mar 22, 2024, Jeff Law wrote:
On 3/9/24 2:11 AM, Alexandre Oliva wrote:
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes repo
On 1/18/24 12:54 PM, Roger Sayle wrote:
This patch tweaks RTL expansion of multi-word shifts and rotates to use
PLUS rather than IOR for disjunctive operations. During expansion of
these operations, the middle-end creates RTL like (X<>C2)
where the constants C1 and C2 guarantee that bits don
LT/LE: c.lt.fmt/c.le.fmt on pre-R6 and cmp.lt.fmt/cmp.le.fmt have
different semantic:
c.lt.fmt will signal for all NaN, including qNaN;
cmp.lt.fmt will only signal sNaN, while not qNaN;
cmp.slt.fmt has the same semantic as c.lt.fmt;
lt/le of RTL will signaling qNaN.
while in `s__using_
On Mon, 3 Jun 2024, Richard Biener wrote:
> install.texi also has the issue that it's not pre-packaged in a
> easy to discover and readable file in the release tarballs and that
> the online version is only for trunk.
The latter is only partially true: we generally try to keep it applicable
more
On 5/29/24 5:12 AM, Mariam Arutunian wrote:
IIRC we looked at the problem of canonicalizing the loop into a form
where we didn't necessarily have conditional blocks, instead we had
branchless sequences for the conditional xor and dealing with the high
bit in the crc. My reco
On 5/27/24 7:51 AM, Mariam Arutunian wrote:
I carefully reviewed the indentation of the code using different editors
and viewers, and everything appeared correct.
I double-checked the specific sections mentioned, and they also looked
right.
In this reply message I see that it's not correc
On 6/4/24 7:41 AM, Mariam Arutunian wrote:
/Mariam, your thoughts on whether or not those two phases could handle a
loop with two CRC calculations inside, essentially creating two calls to
our new builtins? /
/
/
It is feasible, but it would likely demand considerable effort and
additiona
On 5/14/24 8:12 AM, Gabi Falk wrote:
Hi,
This one still needs review:
https://inbox.sourceware.org/gcc-patches/20240415233833.104460-1-gabif...@gmx.com/
I think I just ACK'd an equivalent patch from someone else this week.
jeff
On 3/1/24 1:12 AM, Demin Han wrote:
Hi juzhe,
I also thought it’s related to commutive firstly.
Following things make me to do the removal:
1.No tests fails in regression
2.When I write if (a == 2) and if (2 == a), the results are same
GCC canonicalizes comparisons so that constants appea
On Sat, Jun 8, 2024 at 2:09 PM Gerald Pfeifer wrote:
>
> On Sat, 8 Jun 2024, Uros Bizjak wrote:
> > gcc/ChangeLog:
> >
> > * config/i386/i386.md (usadd3): New expander.
> > (x86_movcc_0_m1_neg): Use SWI mode iterator.
>
> When you write "committed", did you actually push?
Yes, IIRC, the r
On 2/29/24 11:27 PM, demin.han wrote:
We can unify eqne and other comparison operations.
Tested on RV32 and RV64
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: Remove eqne cond
* config/riscv/vector.md (@pred_eqne_scalar): Remove patterns
(*pred_eqne_s
On 5/16/24 1:21 PM, Robin Dapp wrote:
Can eqne pattern removal patches be committed firstly?
Please first make sure you test with corner cases, NaNs in
particular. I'm pretty sure we don't have any test cases for
those.
But isn't canonicalization of EQ/NE safe, even for IEEE NaN and +-0.0?
On 6/5/24 8:42 PM, Fei Gao wrote:
But let's back up and get a good explanation of what the problem is.
Based on patch 2/2 it looks like we have lost an assignment to the
return register.
To someone not familiar with this code, it sounds to me like we've made
a mistake earlier and we're now d
Andre Vehreschild wrote:
PS That's good news about the funding. Maybe we will get to see "built in"
coarrays soon?
You hopefully will see Nikolas work on the shared memory coarray support, if
that is what you mean by "built in" coarrays. I will be working on the
distributed memory coarray suppor
On 6/6/24 8:51 PM, Jin Ma wrote:
I am very sorry that I did not check the commit information carefully. The
statement is somewhat inaccurate.
When the insn 1 and 2, 3 and 4 can be fusioned, then there is the
following sequence:
;; insn |
;; 1 | sp=sp-0x18
;; + 2 | [sp+0x10]=r
On Sat, 8 Jun 2024 at 16:56, Ulrich Drepper wrote:
>
> On Sat, Jun 8, 2024 at 5:03 PM Jonathan Wakely wrote:
> > I'm in two minds about backporting this one. It would be good to fix the
> > non-conformance problem for the release branches, but it also
> > potentially breaks some code that uses ra
Hi Gerald,
Gerald Pfeifer wrote:
Looks like a janitorial task to fix the absolute links, possibly
excluding those with /git, /onlinedocs, /wiki – or assuming that the
main page is GCC.gnu.org, relying on the redirects.
It's on my list. A first quick check indicates there isn't much to do,
thoug
On 5/29/24 8:07 PM, Jeff Law wrote:
On 5/29/24 7:28 PM, Hans-Peter Nilsson wrote:
From: Hans-Peter Nilsson
Date: Mon, 27 May 2024 19:51:47 +0200
2: Does not depend on 1, but corrects an incidentally found wart:
find_basic_block calls fails too often. Replace it with "modern"
insn-to-ba
On Sat, Jun 8, 2024 at 5:03 PM Jonathan Wakely wrote:
> I'm in two minds about backporting this one. It would be good to fix the
> non-conformance problem for the release branches, but it also
> potentially breaks some code that uses ranges::iota without including
> .
I say add the change as soon
Here's what I pushed to trunk, using the macro instead of the plain
keyword, and with a testcase.
Thanks for the patch, Deev.
Tested x86_64-linux. Pushed to trunk. I'll backport this too.
-- >8 --
This is called from the std::atomic constructor,
which needs to be usable in constant expressions.
From: Michael Levine
I committed the missing include separately, and pushed Michael's change
as attached (with some whitespace tweaks and a changelog entry).
Thanks for the patch, Michael!
Tested x86_64-linux. Pushed to trunk.
I'm in two minds about backporting this one. It would be good to fi
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The __cpp_lib_ranges macro is missing from .
libstdc++-v3/ChangeLog:
* include/std/algorithm: Define __glibcxx_want_ranges.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc: Check
feature test macro in C++20 mode.
---
On 6/8/24 1:53 AM, Richard Sandiford wrote:
I realise there are many ways of writing this out there though,
so that's just a suggestion. (And only lightly tested.)
FWIW, we could easily extend the interface to work on wide_ints if we
ever need it for N>63.
I think there's constraints elsew
This patch reuses the MinGW implementation to enable DLL import/export
functionality for the aarch64-w64-mingw32 target. It also modifies
environment configurations for MinGW.
gcc/ChangeLog:
* config.gcc: Add winnt-dll.o, which contains the DLL
import/export implementation.
The DLL import/export mingw implementation, originally from ix86, requires
minor adjustments to be compatible with AArch64.
gcc/ChangeLog:
* config/i386/cygming.h (PE_COFF_EXTERN_DECL_SHOULD_BE_LEGITIMIZED):
Declare whether an external declaration should be legitimized.
(H
This patch extends the aarch64 attributes list with the selectany
attribute for the aarch64-w64-mingw32 target and reuses the mingw
implementation to handle it.
* config/aarch64/aarch64.cc:
Extend the aarch64 attributes list.
* config/aarch64/cygming.h (SUBTARGET_ATTRIBUTE_
This patch renames functions related to dllimport/dllexport
and selectany functionality. These functions will be reused
in the aarch64-w64-mingw32 target.
gcc/ChangeLog:
* config/i386/cygming.h (mingw_pe_record_stub):
Rename functions in mingw folder which will be reused for
From 8f6fd4775792b443a72dfbc8d95bf3ff5b516d18 Mon Sep 17 00:00:00 2001
From: Evgeny Karpov
Date: Thu, 6 Jun 2024 22:38:35 +0200
Subject: [PATCH v3 2/6] Extract ix86 dllimport implementation to mingw
This patch extracts the ix86 implementation for expanding a SYMBOL
into its corresponding dllimpo
v3-0002-Extract-ix86-dllimport-implementation-to-mingw.patch
Description: v3-0002-Extract-ix86-dllimport-implementation-to-mingw.patch
This patch refactors recent changes to move mingw-related
functionality to the mingw folder. More renamings to the mingw_
prefix will be done in follow-up commits.
This is the first commit in the second patch series to add DLL
import/export implementation to AArch64.
Coauthors: Zac Walker ,
Mark
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6):
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6):
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6):
This patch makes changes to the i386.cc file, which contains the ASCII 0x0C
character. However, this character was replaced by the mail client, and the
patchwork could not validate the series. I am resubmitting the patch as an
attachment.
v2-0002-Extract-ix86-dllimport-implementation-to-mingw
On Sat, 8 Jun 2024, Uros Bizjak wrote:
> gcc/ChangeLog:
>
> * config/i386/i386.md (usadd3): New expander.
> (x86_movcc_0_m1_neg): Use SWI mode iterator.
When you write "committed", did you actually push?
If so, us being on Git now it might be good to adjust terminology.
Gerald
Thanks for Tobias for pointing these two out.
Pushed.
Gerald
---
htdocs/gcc-14/porting_to.html | 2 +-
htdocs/gcc-5/changes.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index ef02e071..3de15d02 1006
On Fri, 7 Jun 2024, Tobias Burnus wrote:
>> + https://gcc.gnu.org/projects/gomp/";>OpenMP
>> Can you please make this a relative link, i.e. "../projects/gomp/"?
> Good point. I thought such links should be absolute because of (www.)GNU.org,
> i.e.
>
> https://www.gnu.org/software/gcc/releases.htm
Mariam Arutunian writes:
> This patch introduces two new expanders for the aarch64 backend,
> dedicated to generate optimized code for CRC computations.
> The new expanders are designed to leverage specific hardware capabilities
> to achieve faster CRC calculations,
> particularly using the pmul o
Hi Jason,
On 7 Jun 2024, at 19:30, Jason Merrill wrote:
> On 6/7/24 08:12, Simon Martin wrote:
>> We ICE upon the following when trying to emit a
>> -Wlogical-not-parentheses
>> warning:
>>
>> === cut here ===
>> template T foo (T arg, T& ref, T* ptr) {
>>int a = 1;
>>return static_cast
When showing a list of options marked up as code, each individual option
should be marked up, not the entire list and he commas as part of that.
Pushed.
Gerald
---
htdocs/gcc-12/changes.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdoc
The following testcase:
unsigned
add_sat(unsigned x, unsigned y)
{
unsigned z;
return __builtin_add_overflow(x, y, &z) ? -1u : z;
}
currently compiles (-O2) to:
add_sat:
addl%esi, %edi
jc .L3
movl%edi, %eax
ret
.L3:
orl $-1, %eax
> LGTM.
Committed, thanks Robin.
> Let's keep in mind that min/max will save us two insns(?)
> and a conditional move would save us one.
Got it, cmov is well designed for such case(s).
Pan
-Original Message-
From: Robin Dapp
Sent: Friday, June 7, 2024 9:57 PM
To: Li, Pan2 ; gcc-patc
In mips.cc(mips_reorg_process_insns), there is this claim:
Also delete cache barriers if the last instruction
was an annulled branch. INSN will not be speculatively
executed.
And with -O1 on mips64, we can generate binary code like this,
which fails this test.
gcc/testsuite
Thanks a lot for doing this! It's a really nice series.
Just had a comment on the long division helper:
Mariam Arutunian writes:
> +/* Return the quotient of polynomial long division of x^2N by POLYNOMIAL
> + in GF (2^N). */
It looks like there might be an off-by-one discrepancy between the
Note this is more than just http->https.
Pushed.
Gerald
---
htdocs/news.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index aeac6935..5f652d90 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -678,13 +678,13 @@ platforms
46 matches
Mail list logo
