> -Original Message-
> From: Richard Biener
> Sent: Friday, June 14, 2024 2:52 PM
> To: Kong, Lingling
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ; Uros
> Bizjak
> Subject: Re: [PATCH 0/3] [APX CFCMOV] Support APX CFCMOV
>
> On Fri, Jun 14, 2024 at 5:12 AM Kong, Lingling
> wrote:
>
On Fri, Jun 14, 2024 at 5:12 AM Kong, Lingling wrote:
>
> APX CFCMOV[1] feature implements conditionally faulting which means that all
> memory faults are suppressed
> when the condition code evaluates to false and load or store a memory
> operand. Now we could load or store a
> memory operand m
> -Original Message-
> From: Richard Biener
> Sent: Friday, June 14, 2024 2:13 PM
> To: Kong, Lingling ; Richard Sandiford
>
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ; Uros
> Bizjak
> Subject: Re: [PATCH 2/2] [APX CFCMOV] Support APX CFCMOV
>
> On Fri, Jun 14, 2024 at 3:39 AM Kong,
On Fri, Jun 14, 2024 at 3:39 AM Kong, Lingling wrote:
>
> From: konglin1
>
>
>
> APX CFCMOV feature implements conditionally faulting which means that all
>
> memory faults are suppressed when the condition code evaluates to false and
>
> load or store a memory operand. Now we could load or store
On Fri, Jun 14, 2024 at 3:21 AM Li, Pan2 wrote:
>
> Thanks for another try.
>
> Looks the build failure list below has nothing to do with this patch. I think
> the correlated owner will take care of this Werror build issue soon.
>
> Pan
>
> -Original Message-
> From: Maciej W. Rozycki
>
Hi,
on 2024/6/14 11:58, Peter Bergner wrote:
> On 6/13/24 9:34 PM, Kewen.Lin wrote:
>> on 2024/6/14 05:16, Carl Love wrote:
>
>>> /* { dg-options "-mvsx" } */
>>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>>> has_arch_pwr8 } } } */
>
> With the above, we're going to compi
On Wed, Jun 05, 2024 at 08:00:15AM +0200, Stefan Schulze Frielinghaus wrote:
With the change of r15-787-g57e04879389f9c I forgot to also update this
test.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc.
Ok. Thanks!
Andreas
---
Ok for mainline? Ok for
On 6/2/24 14:07, Stefan Schulze Frielinghaus wrote:
Since the patch works fine so far for mainline, ok to backport to GCC 14?
Yes please do. Thanks!
Andreas
On Fri, May 17, 2024 at 08:59:05AM +0200, Stefan Schulze Frielinghaus wrote:
I've adapted the patch as follows and will push.
Than
Hi Paul,
on 2024/6/14 04:07, Paul Koning wrote:
> What is the effect of this change? The original code intended to have
> "float" mean a 32 bit value, and "double" a 64 bit value. There aren't any
> larger floats, so I defined the long double size as 64 also. Is the right
> answer not to def
Regenerate the patch due to changes on its dependent patches.
Thanks,
Feng,
---
gcc/
PR tree-optimization/114440
* tree-vectorizer.h (struct _stmt_vec_info): Add a new field
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
On 6/13/24 9:34 PM, Kewen.Lin wrote:
> on 2024/6/14 05:16, Carl Love wrote:
>> /* { dg-options "-mvsx" } */
>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>> has_arch_pwr8 } } } */
With the above, we're going to compile and run this test case with -mcpu=power8
or higher, whi
Updated the patch.
Thanks,
Feng
--
gcc/
* tree-vect-loop.cc (vectorizable_reduction): Set STMT_VINFO_REDUC_DEF
for non-live stmt.
* tree-vect-stmts.cc (vectorizable_condition): Treat the condition
statement that is pointed by stmt_vec_info of reduction PHI as the
On 6/13/24 9:26 PM, Kewen.Lin wrote:
> on 2024/6/13 21:24, Peter Bergner wrote:
>> On 6/13/24 12:35 AM, Kewen.Lin wrote:
@@ -826,7 +826,14 @@ rs6000_stack_info (void)
info->ehrd_offset -= info->rop_hash_size;
}
else
- info->ehrd_offset = info->gp_save_offset
From: Lingling Kong
Handle target hook TARGET_HAVE_CONDITIONAL_MOVE_MEM_NOTRAP and support
CFCMOV in backend.
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_can_cfcmov_p): New function that
test if the cfcmov can be generated.
(ix86_expand_int_movcc): Expand to cfcmo
From: Lingling Kong
After added target HOOK TARGET_HAVE_CONDITIONAL_MOVE_MEM_NOTRAP,
we could support a conditional move that load or store mem may trap
or fault in if convert pass.
Conditional move suppress fault for conditional mem store would not
move any arithmetic calculations. For conditio
From: konglin1
APX CFCMOV feature implements conditionally faulting which means that all
memory faults are suppressed when the condition code evaluates to false and
load or store a memory operand. Now we could load or store a memory operand
may trap or fault for conditional move.
In middle-end,
APX CFCMOV[1] feature implements conditionally faulting which means that all
memory faults are suppressed
when the condition code evaluates to false and load or store a memory operand.
Now we could load or store a
memory operand may trap or fault for conditional move.
In middle-end, now we don't
Thanks Juzhe, will commit the series after the middle-end patch.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, June 14, 2024 10:24 AM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; jeffreyalaw ;
Robin Dapp ; Li, Pan2
Subject: Re: [PATCH v1 1/8] RISC-V: Add testcases for scalar unsigned SAT_SUB
f
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 8/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form
10
From: Pan Li
After the middle-end support the form 10 of unsigned SAT
on 2024/6/13 21:24, Peter Bergner wrote:
> On 6/13/24 12:35 AM, Kewen.Lin wrote:
>>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>> info->ehrd_offset -= info->rop_hash_size;
>>> }
>>>else
>>> - info->ehrd_offset = info->gp_save_offset - ehrd_size;
>>> + {
>>> + info->eh
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 6/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 8
From: Pan Li
After the middle-end support the form 8 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 2/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 4
From: Pan Li
After the middle-end support the form 4 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 5/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 7
From: Pan Li
After the middle-end support the form 7 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 4/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 6
From: Pan Li
After the middle-end support the form 6 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 7/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 9
From: Pan Li
After the middle-end support the form 9 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 3/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 5
From: Pan Li
After the middle-end support the form 5 of unsigned SAT_SU
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-14 10:13
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1 1/8] RISC-V: Add testcases for scalar unsigned SAT_SUB form 3
From: Pan Li
After the middle-end support the form 3 of unsigned SAT_SU
Hi David,
on 2024/6/13 21:44, David Malcolm wrote:
> On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as he and Richi suggested, the existing macros
>> {FLOAT,{,LONG_}
From: Pan Li
After the middle-end support the form 10 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 10 of unsigned .SAT_SUB.
Form 10:
#define SAT_SUB_U_10(T) \
T sat_sub_u_10_##T (T x, T y) \
{ \
T ret; \
T overflow =
From: Pan Li
After the middle-end support the form 9 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 9 of unsigned .SAT_SUB.
Form 9:
#define SAT_SUB_U_9(T) \
T sat_sub_u_9_##T (T x, T y) \
{ \
T ret; \
T overflow = __bu
From: Pan Li
After the middle-end support the form 6 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 6 of unsigned .SAT_SUB.
Form 6:
#define SAT_SUB_U_6(T) \
T sat_sub_u_6_##T (T x, T y) \
{ \
return x <= y ? 0 : x - y; \
From: Pan Li
After the middle-end support the form 7 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 7 of unsigned .SAT_SUB.
Form 7:
#define SAT_SUB_U_7(T) \
T sat_sub_u_7_##T (T x, T y) \
{ \
T ret; \
T overflow = __bu
From: Pan Li
After the middle-end support the form 5 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 5 of unsigned .SAT_SUB.
Form 5:
#define SAT_SUB_U_5(T) \
T sat_sub_u_5_##T (T x, T y) \
{ \
return x < y ? 0 : x - y; \
From: Pan Li
After the middle-end support the form 8 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 8 of unsigned .SAT_SUB.
Form 8:
#define SAT_SUB_U_8(T) \
T sat_sub_u_8_##T (T x, T y) \
{ \
T ret; \
T overflow = __bu
From: Pan Li
After the middle-end support the form 4 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 4 of unsigned .SAT_SUB.
Form 4:
#define SAT_SUB_U_4(T) \
T sat_sub_u_4_##T (T x, T y) \
{ \
return x >= y ? x - y : 0; \
From: Pan Li
After the middle-end support the form 3 of unsigned SAT_SUB and
the RISC-V backend implement the scalar .SAT_SUB, add more test
case to cover the form 3 of unsigned .SAT_SUB.
Form 3:
#define SAT_SUB_U_3(T) \
T sat_sub_u_3_##T (T x, T y) \
{ \
return x > y ? x - y : 0; \
On 6/13/24 7:54 PM, Andrew Pinski wrote:
While working on an expand patch back in January I noticed that
the first argument (of sepops type) of expand_expr_real_2 could be
constified as it was not to be touched by the function (nor should it be).
There is code in internal-fn.cc that depends on
While working on an expand patch back in January I noticed that
the first argument (of sepops type) of expand_expr_real_2 could be
constified as it was not to be touched by the function (nor should it be).
There is code in internal-fn.cc that depends on expand_expr_real_2 not touching
the ops argum
On Jun 13, 2024, Hongyu Wang wrote:
> I think the function name can be like ix86_unroll_flag_adjust instead
> of ix86_override_options_after_change_1, like the previous 2 functions
> which declares the usage more clearly.
I'd be happy to rename it, but we have a long-established convention of
us
From: konglin1 mailto:lingling.k...@intel.com>>
APX CFCMOV feature implements conditionally faulting which means that all
memory faults are suppressed when the condition code evaluates to false and
load or store a memory operand. Now we could load or store a memory operand
may trap or fault f
From: konglin1
gcc/ChangeLog:
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Add TARGET_HAVE_CONDITIONAL_MOVE_MEM_NOTRAP
* target.def (bool,): New hook.
* targhooks.cc (default_have_conditional_move_mem_notrap): New
function to hook TARGET_HAVE_CONDITIONAL_
This patch updates the GCC x86 backend to efficiently handle
odd, incrementally increasing permutations of BF16 vectors
using the cvtne2ps2bf16 instruction.
It modifies ix86_vectorize_vec_perm_const to support these operations
and adds a specific predicate to ensure proper sequence handling.
Boots
gcc/ChangeLog:
* config/i386/i386-expand.cc
(ix86_vectorize_vec_perm_const): Convert BF to HI using subreg.
* config/i386/predicates.md
(vcvtne2ps2bf_parallel): New define_insn_and_split.
* config/i386/sse.md
(vpermt2_sepcial_bf16_shuffle_): New pred
Thanks for another try.
Looks the build failure list below has nothing to do with this patch. I think
the correlated owner will take care of this Werror build issue soon.
Pan
-Original Message-
From: Maciej W. Rozycki
Sent: Friday, June 14, 2024 12:15 AM
To: Li, Pan2
Cc: Richard Bien
Collin Funk writes:
> When dlopen and pthread_create are in libc the variable is
> set to "none required", therefore running configure will show
> the following errors:
>
> ./configure: line 8997: test: too many arguments
> ./configure: line 8999: test: too many arguments
> ./configure: line 9003
When dlopen and pthread_create are in libc the variable is
set to "none required", therefore running configure will show
the following errors:
./configure: line 8997: test: too many arguments
./configure: line 8999: test: too many arguments
./configure: line 9003: test: too many arguments
./config
> Pengxuan Zheng writes:
> > This patch improves GCC’s vectorization of __builtin_popcount for
> > aarch64 target by adding popcount patterns for vector modes besides
> > QImode, i.e., HImode, SImode and DImode.
> >
> > With this patch, we now generate the following for V8HI:
> > cnt v1.16b,
On Jun 11, 2024, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu. Pre-approved by Eric. I'm checking it
> in.
... I've just reverted it. It turned out to be too easy to be good :-(
There were various regressions, including infinite loops in the compiler
to GDB regressions yet to be i
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for V8HI:
cnt v1.16b, v.16b
uaddlp v2.8h, v1.16b
For V4HI, we gene
On 6/13/24 12:58, Jeff Law wrote:
On 6/12/24 6:10 PM, Patrick O'Neill wrote:
Andrea Parri recently pointed out that we were emitting overly
conservative
fences for seq_cst atomic loads/stores. This adds support for the
optimized
fences specified in the PSABI:
https://github.com/riscv-non-i
Andrea Parri recently pointed out that we were emitting overly conservative
fences for seq_cst atomic loads/stores. This adds support for the optimized
fences specified in the PSABI:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/2092568f7896ceaa1ec0f02569b19eaa42cd51c9/riscv-atomic.adoc
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to upgrade Zaamo/Zalrsc to 'a' when the assember does not support it.
This change respects Zaamo/Zalrsc when generating code.
Testcases that check for the default isa string will fail with the old binutils
since zaamo/zalr
Support for complex increment and decrement (previously supported as
an extension) was voted into C2Y today (paper N3259). Thus, change
the pedwarn to a pedwarn_c23 and add associated tests.
Note: the type of the 1 to be added / subtracted is underspecified (to
be addressed in a subsequent paper)
Segher:
On 6/13/24 12:51, Segher Boessenkool wrote:
>
>> --- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target powerpc*-*-* } } */
>> +/* { dg-do run { target powerpc*-*-* }
GCC maintainers:
As noted the removal of __builtin_vsx_xvcvdpuxds_uns and
__builtin_vsx_xvcvspuxws was moved to patch 2 in the seris. The patch has been
updated per the comments from version 3.
Please let me know if this patch is acceptable for mainline.
Carl
Hi Both,
Thanks for the highly constructive comments. I think that I have
incorporated them fully in the attached.
OK for mainline and ...?
Paul
On Mon, 10 Jun 2024 at 08:19, Andre Vehreschild wrote:
> Hi Paul,
>
> while looking at your patch I see calls to gfc_add_init_cleanup (...,
> back)
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode =
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match
gcc/ChangeLog:
The following testcases have been failing on rv32 targets since
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler
error: in maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess
errors)
Fix the bu
GCC maintainers:
The patch has been updated per the comments from version 3. Please let me know
if the patch is acceptable for mainline.
Carl
-
rs6000, add overloaded vec_sel with int128 arguments
Extend
Kewen:
On 6/3/24 22:59, Kewen.Lin wrote:
> Hi,
>
> on 2024/5/30 00:16, Carl Love wrote:
>> This was patch 13 from the previous series. Note the previous series patch
>> 12 was dropped. This patch is the same as the previous version. The
>> additional work to remove __builtin_vec_set_v1ti, _
On 6/12/24 7:06 AM, Jan Beulich wrote:
For one setting ld_ver in a conditional (no in-tree ld) when it's used,
for x86 at least, in unconditional ways can't be quite right. And then
prefixing relative paths to binaries with ${objdir}/, when ${objdir}
nowadays resolves to just .libs, can at bes
What is the effect of this change? The original code intended to have "float"
mean a 32 bit value, and "double" a 64 bit value. There aren't any larger
floats, so I defined the long double size as 64 also. Is the right answer not
to define it?
That part I understand, but why does the patch a
GCC maintainers:
I have addressed the comments to the five patches in the series that have not
yet been approved.
The patches that have already been approved are 1, 3, 5, 6, 8, 9, 10, and 12.
The remaining patches all have fairly minor fixes requested. I will just post
version 4 of these patch
On 6/12/24 5:20 PM, Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subse
On 6/12/24 6:10 PM, Patrick O'Neill wrote:
Andrea Parri recently pointed out that we were emitting overly conservative
fences for seq_cst atomic loads/stores. This adds support for the optimized
fences specified in the PSABI:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/2092568f78
Hi!
On Thu, Jun 13, 2024 at 11:32:58AM -0700, Carl Love wrote:
> The test gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c is supposed to
> be a runnable test
> to verify the execution of the vec_unpackl and vec_unpackh built-ins. The
> dg-do command is set to
> compile not run. This patc
GCC maintainers:
The patch has been updated per the feedback from version 3. Please let me know
it the patch is acceptable for mainline.
Thanks.
Carl
--
rs6000, remove vector set and vector
GCC maintainers:
The patch has been updated per the comments from version 3. Please let me know
if the patch is acceptable for mainline.
Thanks.
Carl
-
rs6000, extend vec_xxpermdi built-in for __int128 ar
GCC maintainers:
Per the comments on patch 0004 from version 3, the removal of
The built-in __builtin_vsx_xvcvdpuxds_uns and __builtin_vsx_xvcvspuxws was
moved to this patch. The rest of the patch is unchanged from version 3. There
were no comments on this patch for version 3.
Please let me
On Thu, 13 Jun 2024 at 19:57, Jonathan Wakely wrote:
>
> On Thu, 13 Jun 2024 at 18:40, François Dumont wrote:
> >
> > Hi
> >
> > Following your recent change here:
> >
> > https://gcc.gnu.org/pipermail/libstdc++/2024-June/058998.html
> >
> > I think we also need to fix the memset at bucket alloca
On Thu, 13 Jun 2024 at 18:40, François Dumont wrote:
>
> Hi
>
> Following your recent change here:
>
> https://gcc.gnu.org/pipermail/libstdc++/2024-June/058998.html
>
> I think we also need to fix the memset at bucket allocation level.
>
> I did it trying also to be more fancy pointer friendly by
GCC maintainers:
The test gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c is supposed to
be a runnable test
to verify the execution of the vec_unpackl and vec_unpackh built-ins. The
dg-do command is set to
compile not run. This patch fixes the dg-do command argument.
The patch has bee
Per codingconventions.html; noticed reviewing a patch that went in already
(touching something else actually).
Pushed.
Gerald
gcc:
* doc/extend.texi (AArch64 Function Attributes): Add
(AVR Variable Attributes): Ditto.
(Common Type Attributes): Ditto.
---
gcc/doc/extend
On 6/13/24 10:10 AM, Andi Kleen wrote:
Manolis Tsamis writes:
Assembly like this can appear with bitfields or type punning / unions.
On stress-ng when running the cpu-union microbenchmark the following speedups
have been observed.
Neoverse-N1: +29.4%
Intel Coffeelake: +13.1%
Thanks for the update!
In terms of high-level comments:
- It looks like the code processes normal pseudos as well as subregs.
Is that necessary? The handling of single-register pseudos should
be fully redundant with the normal liveness tracking.
I think if possible we should just process
OK with me.
On 6/13/24 00:16, Kewen.Lin wrote:
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653355.html
BR,
Kewen
on 2024/6/3 11:01, Kewen Lin wrote:
This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
defines in microblaze port.
gcc/ChangeLog:
* conf
Hi
Following your recent change here:
https://gcc.gnu.org/pipermail/libstdc++/2024-June/058998.html
I think we also need to fix the memset at bucket allocation level.
I did it trying also to be more fancy pointer friendly by running
__uninitialized_default_n_a on the allocator returned pointe
On Thu, 13 Jun 2024, Maciej W. Rozycki wrote:
> > This was tricky to duplicate without access to an alpha-linux-gnu
> > machine. I ended up building an uberbaum tree with --disable-shared
> > --disable-threads --enable-languages=ada up to all-target-libgcc, then I
> > replaced gcc/collect2 with a
On Thu, 13 Jun 2024, Jason Merrill wrote:
> On 6/13/24 11:05, Patrick Palka wrote:
> > On Thu, 23 May 2024, Jason Merrill wrote:
> >
> > > On 5/23/24 17:42, Patrick Palka wrote:
> > > > On Thu, 23 May 2024, Jason Merrill wrote:
> > > >
> > > > > On 5/23/24 14:06, Patrick Palka wrote:
> > > > > >
On Thu, 23 May 2024, Jason Merrill wrote:
> On 5/23/24 17:42, Patrick Palka wrote:
> > On Thu, 23 May 2024, Jason Merrill wrote:
> >
> > > On 5/23/24 14:06, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk/14?
> > > >
> > > > --
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Currently we represent a non-function using-declaration by inserting the
named declaration into the target scope. In general this works fine, but in
the case of an exported using-declaration we have nowhere to mark the
using-declaration as
On Wed, 12 Jun 2024, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> exception_ptr.h contains
>
> namespace __exception_ptr
> {
> class exception_ptr;
> }
> using __exception_ptr::exception_ptr;
>
> so when module std tries to 'export using st
On 6/13/24 10:31, Ken Matsui wrote:
This patch adds a warning switch for "#pragma once in main file". The
warning option name is Wpragma-once-outside-header, which is the same
as Clang.
PR preprocessor/89808
gcc/c-family/ChangeLog:
* c.opt (Wpragma_once_outside_header): Define
On 6/13/24 11:05, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 17:42, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 14:06, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8
Manolis Tsamis writes:
>
> Assembly like this can appear with bitfields or type punning / unions.
> On stress-ng when running the cpu-union microbenchmark the following speedups
> have been observed.
>
> Neoverse-N1: +29.4%
> Intel Coffeelake: +13.1%
> AMD 5950X:+17.5%
It seems
On Thu, 13 Jun 2024, Li, Pan2 wrote:
> Could you please help to update the upstream for another try ?
>
> Should be fixed by this commit
> https://github.com/gcc-mirror/gcc/commit/d03ff3fd3e2da1352a404e3c53fe61314569345c.
>
> Feel free to ping me if any questions or concerns.
Upstream master
On Tue, Jun 4, 2024 at 7:54 AM Jason Merrill wrote:
>
> On 3/14/24 04:01, Ken Matsui wrote:
> > On Sat, Mar 2, 2024 at 5:04 AM Ken Matsui wrote:
> >>
> >> This patch adds a warning switch for "#pragma once in main file". The
> >> warning option name is Wpragma-once-outside-header, which is the s
Juzhe-Zhong writes:
> ---
> gcc/common.opt | 4
> gcc/common.opt.urls | 3 +++
> gcc/doc/invoke.texi | 8
> gcc/opts.cc | 1 +
> 4 files changed, 16 insertions(+)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 40cab3cb36a..5710e817abe 100644
> --- a/gcc/common
Kewen:
On 6/3/24 22:58, Kewen.Lin wrote:
> Hi,
>
> on 2024/5/30 00:10, Carl Love wrote:
>> This was patch 10 from the previous series. The patch was updated to
>> address feedback comments.
>>
>> Carl
>> ---
>>
>> rs6
Kewen:
On 6/3/24 22:58, Kewen.Lin wrote:
> Hi,
>
> on 2024/5/30 00:03, Carl Love wrote:
>> This was patch 6 in the previous series. Updated the documentation file per
>> the comments. No functional changes to the patch.
>>
>> Carl
>> -
Kewen:
On 6/4/24 00:19, Kewen.Lin wrote:
> Hi,
>
> on 2024/5/29 23:58, Carl Love wrote:
>> Updated the patch per the feedback comments from the previous version.
>>
>> Carl
>> ---
>>
>> rs6000, extend the curren
On 6/13/24 11:16, Patrick Palka wrote:
On Wed, 12 Jun 2024, Jason Merrill wrote:
exception_ptr.h contains
namespace __exception_ptr
{
class exception_ptr;
}
using __exception_ptr::exception_ptr;
so when module std tries to 'export using std::exception_ptr', it names
another u
On Thu, 13 Jun 2024 at 15:16, Jonathan Wakely wrote:
>
> On Thu, 13 Jun 2024 at 15:11, Jeff Law wrote:
> >
> >
> >
> > On 6/13/24 4:33 AM, Jonathan Wakely wrote:
> > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner
> > > wrote:
> > >>
> > >> Hi Jonathan, Richard,
> > >>
> > >> On 12.06.24 20:54,
On Thu, 2024-06-13 at 07:31 -0700, Ken Matsui wrote:
> This patch adds a warning switch for "#pragma once in main file".
> The
> warning option name is Wpragma-once-outside-header, which is the same
> as Clang.
>
> PR preprocessor/89808
>
> gcc/c-family/ChangeLog:
>
> * c.opt (W
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
add_binding_entity creates an OVERLOAD to represent a using-declaration in
module purview of a declaration in the global module, even for
non-functions, and we were failing to merge that with the original
declaration in name lookup.
It's no
> I did a test run without the subreg condition and it also appears to
> work when running on rv32gcv and rv64gcv newlib. Would it be better
> to remove the subreg?
Yep, if it works, i.e. all tests still pass then let's get rid of it.
Regards
Robin
This patch adds a warning switch for "#pragma once in main file". The
warning option name is Wpragma-once-outside-header, which is the same
as Clang.
PR preprocessor/89808
gcc/c-family/ChangeLog:
* c.opt (Wpragma_once_outside_header): Define new option.
gcc/ChangeLog:
On 6/13/24 5:40 AM, Manolis Tsamis wrote:
Could you please run the v3 with your tester? I assume some of the
additional fixes introduced may clear some of the other issues.
Will do.
jeff
On Thu, 13 Jun 2024 at 15:11, Jeff Law wrote:
>
>
>
> On 6/13/24 4:33 AM, Jonathan Wakely wrote:
> > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner wrote:
> >>
> >> Hi Jonathan, Richard,
> >>
> >> On 12.06.24 20:54, Jonathan Wakely wrote:
> >>> On 12/06/24 16:09 +0200, Frank Scheiner wrote:
>
1 - 100 of 204 matches
Mail list logo
