If you build a little endian compiler and select a default CPU of power5
(i.e. --with-cpu=power5), GCC cannot be built. The reason is that both the
libgfortran and libstdc++-v3 libraries assume that all little endian powerpc
builds support IEEE 128-bit floating point.
However, if the default cpu
Note, this is a repost of the 3 patches I posted on June 4th. The first two
patches are the same. The third patch modifies the power11 tests to do a
compile instead of assemble, and I removed the power11 specific target support
that was posted as suggested by Kewen.Lin.
The following 3 patches a
[This is a repost of the June 4th patch]
This patch adds the power11 option to the -mcpu= and -mtune= switches.
This patch treats the power11 like a power10 in terms of costs and reassociation
width.
This patch issues a ".machine power11" to the assembly file if you use
-mcpu=power11.
This patc
[This is a repost of the June 4th patch]
This patch makes -mtune=power11 use the same tuning decisions as -mtune=power10.
This patch makes -mtune=power11 use the same tuning decisions as
-mtune=power10. It needs the previous patch to be applied.
I have bootstrapped these patches on both little
This patch is a modification of the patch posted on June 4th. It only does a
compile of the tests, and not an assemble as suggested by Kewen.Lin. I have
removed the power11 target support option that was previously added.
This patch adds some simple tests for -mcpu=power11 support.
I have boots
On 02/07/24 16:40, Jeff Law wrote:
> [ Actually attaching the patch this time... ]
>
> The pre-commit testing showed that making ext-dce only active at -O2 and
> above would require minor edits to the tests. In some cases we had specified
> -O1 in the test or specified no optimization level
On 7/10/24 11:42 AM, Adhemerval Zanella Netto wrote:
On 02/07/24 16:40, Jeff Law wrote:
[ Actually attaching the patch this time... ]
The pre-commit testing showed that making ext-dce only active at -O2 and above
would require minor edits to the tests. In some cases we had specified -O1
This patch eliminates an unnecessary sign extension for scalar inlined
string comparisons on rv64.
Conceptually this is pretty simple. Prove all the paths which "return"
a value from the inlined string comparison already have sign extended
values.
FINAL_LABEL is the point after the calculat
Richard Biener writes:
> The following is a prototype for how to represent load/store-lanes
> within SLP. I've for now settled with having a single load node
> with multiple permute nodes acting as selection, one for each loaded lane
> and a single store node fed from all stored lanes. For
>
>
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2024/7/8 19:14, Richard Sandiford wrote:
>> "Kewen.Lin" writes:[snip...]
This part looks good to me FWIW, but what's the correct behaviour of:
if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
{
Hi Andre,
Am 10.07.24 um 10:45 schrieb Andre Vehreschild:
Hi Harald,
thanks for the review. I totally agree, that this patch has gotten bigger than
I expected (and wanted). But things are as they are.
About the coding style: I have worked in so many projects, that I consider a
consistent codin
Hi Prathamesh,
Am 10.07.24 um 13:22 schrieb Prathamesh Kulkarni:
Hi,
The attached patch lowers zeroing array assignment to memset for allocatable
arrays.
For example:
subroutine test(z, n)
implicit none
integer :: n
real(4), allocatable :: z(:,:,:)
allocate(z(n, 8192, 2048
On 7/10/24 01:50, Jeff Law wrote:
On 6/25/24 1:56 AM, Jørgen Kvalsvik wrote:
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to f
On Sun, May 26, 2024 at 11:51 PM Max Filippov wrote:
>
> diff --git a/libbacktrace/internal.h b/libbacktrace/internal.h
> index 4fa0af8cb6c9..456911166026 100644
> --- a/libbacktrace/internal.h
> +++ b/libbacktrace/internal.h
> @@ -323,10 +323,22 @@ struct dwarf_sections
>
> struct dwarf_data;
>
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 9cdef19c461..055fa7e78ba 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -1613,6 +1613,12 @@ process_all_
Hi Daniel,
Thanks for patching the Rust frontend as well. Looks great to me.
Best,
Arthur
On 7/10/24 11:43, Daniel Bertalan wrote:
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__nul
A last minute change led to a wrong operand order in the compare insn.
gcc/ChangeLog:
* config/i386/i386.md (ustruncdi2): Swap compare operands.
(ustruncsi2): Ditto.
(ustrunchiqi2): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/config
Pushed to trunk.
On Mon, 8 Jul 2024 at 20:44, Jonathan Wakely wrote:
>
> This fixes another problem with my recent changes to use memchr in
> std::find.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> For an integer-class type we need to use an explicit conversion to size_t.
>
> libstdc++-v3/ChangeLog:
Tested x86_64-linux. Pushed to trunk. Backports could follow.
-- >8 --
The consensus in the standard committee is that this change shouldn't be
necessary, and the Allocator requirements should require conversions
between rebound allocators to be implicit. But we can make it work for
now anyway.
On Wed, Jul 10, 2024 at 3:42 PM haochen.jiang
wrote:
>
> On Linux/x86_64,
>
> 80e446e829d818dc19daa6e671b9626e93ee4949 is the first bad commit
> commit 80e446e829d818dc19daa6e671b9626e93ee4949
> Author: Pan Li
> Date: Fri Jul 5 20:36:35 2024 +0800
>
> Match: Support form 2 for the .SAT_TRUN
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For the C locale we know the encoding is ASCII, so we can avoid using
newlocale and nl_langinfo_l. Similarly, for an unnamed locale, we aren't
going to get a useful answer, so we can just use a default-constrcuted
std::text_encoding representing an u
Tested x86_64-linux. Pushed to trunk. Probably a good idea to backport
it to 13 and 14, for consistency.
-- >8 --
Users are not supposed to create objects of this type, and there's no
reason it needs to be copyable. LWG 4061 makes it non-copyable and
non-default constructible.
libstdc++-v3/Chang
On 7/10/24 21:54, Jeff Law wrote:
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 9cdef19c461..055fa7e78ba 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.c
On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote:
On 7/10/24 21:54, Jeff Law wrote:
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 9cdef19c461..055fa7e
On 7/9/24 11:15 PM, Richard Sandiford wrote:
In this PR, due to the -f flags, we ended up with:
bb1: r10=r10
...
bb2: r10=r10
...
bb3: ...=r10
with bb1->bb2 and bb1->bb3.
late-combine successfully combined the bb1->bb2 def-use and set
the insn code to NOOP_MOVE_INSN_CODE. The bb1->bb3 c
On 6/3/24 5:34 AM, Manolis Tsamis wrote:
This is an extension of what was done in PR106590.
Currently if a sequence generated in noce_convert_multiple_sets clobbers the
condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
(sequences that emit the comparison itself). Since th
On 6/3/24 5:34 AM, Manolis Tsamis wrote:
Currently the operations allowed for if conversion of a basic block with
multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
bb_ok_for_noce_convert_multiple_sets).
This commit allows more operations (arithmetic, compare, etc) to p
On 6/3/24 5:34 AM, Manolis Tsamis wrote:
The existing implementation of need_cmov_or_rewire and
noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
This commit enchances them so they can handle/rewire arbitrary set statements.
To do that a new helper struct noce_multiple_
On 1/15/24 7:04 PM, HAO CHEN GUI wrote:
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports
> I think that's a bug. Do you say __builtin_add_overflow fails to promote
> (constant) arguments?
Thanks Richard. Not very sure which part result in type mismatch, will take a
look and keep you posted.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, July 10, 2024 7:36 P
> OK.
Committed, thanks Richard.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, July 10, 2024 7:26 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
tamar.christ...@arm.com; jeffreya...@gmail.com; rdapp@gmail.com; Liu,
Hongtao
Pushing to trunk.
Thanks,
Kugan
Signed-off-by: Kugan Vivekanandarajah
2024-07-11 Kugan Vivekanandarajah
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 762b91256c4..d27640708c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -704,7 +704,7 @@ Alex
On Wed, Jul 10, 2024 at 10:10 PM Victor Do Nascimento
wrote:
>
> Following the migration of the dot_prod optab from a direct to a
> conversion-type optab, ensure all back-end patterns incorporate the
> second machine mode into pattern names.
The patch LGTM. BTW you can use existing instead of
new
On Wed, 2024-07-10 at 09:43 +, Daniel Bertalan wrote:
> As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
> stddef.h header causes the NULL macro in C++ to be re-defined to an
> integral constant (__null). This makes the workaround in d59a576b8
> ("Redefine NULL to nullptr")
On 7/10/24 1:01 AM, Kewen.Lin wrote:
>> + if (rs6000_rop_protect)
>> +{
>> + /* Disallow CPU targets we don't support. */
>> + if (!TARGET_POWER8)
>> +error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later");
>> +
>> + /* Disallow ABI targets we don't support. */
>>
From: xuli
The reason is that in the following code, icode = movmisalignv8si has
already been rejected by TARGET_VECTOR_MISALIGN_SUPPORTED, but it is
allowed by targetm.slow_unaligned_access,which is contradictory.
(((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothin
Hi,
This patch adds TARGET_FLOAT128_HW into pattern conditions for quad-
precision insns. Also it removes FLOAT128_IEEE_P check from pattern
conditions if the mode of pattern is IEEE128 as the mode iterator -
IEEE128 already checks with FLOAT128_IEEE_P.
For test case float128-cmp2-runnable.c,
on 2024/7/11 11:36, Peter Bergner wrote:
> On 7/10/24 1:01 AM, Kewen.Lin wrote:
>>> + if (rs6000_rop_protect)
>>> +{
>>> + /* Disallow CPU targets we don't support. */
>>> + if (!TARGET_POWER8)
>>> + error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later");
>>> +
>>> +
On 7/10/24 23:59, Jeff Law wrote:
On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote:
On 7/10/24 21:54, Jeff Law wrote:
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 61fa74e9322..87270fd7af4 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -10271,7 +10271,7 @@ riscv_cannot_copy_insn_p (rtx_insn *insn)
> static bool
> riscv_slow_unaligned_access (machine
101 - 140 of 140 matches
Mail list logo
