Late in the development of power10, we discovered that there were some issues
in using load vector pair and store vector pair instructions to do memory
copies, so the defaults were modified to not use these instructions. This
patch re-enables using load and store vector pair instructions.
This patch uses the .machine directive to tell the assembler to use any
possible future instructions.
2024-02-14 Michael Meissner
gcc/
* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Output .machine
future if -mcpu=future.
---
gcc/config/rs6000/rs6000.cc | 2 ++
1
This patch makes -mcpu=future act like -mcpu=power10 in terms of tuning. If
future patches changes the tuning, then this patch woucl be changed to use the
new tuning information. Until there is different tuning, this patch does not
allow the user to explicitly use -mtune=future.
2024-02-14
This patch passes -mfuture to the assembler if the user used -mcpu=future.
2024-02-14 Michael Meissner
gcc/
* config/rs6000/rs6000.h (ASM_CPU_SPEC): If -mcpu=future, pass -mfuture
to the assembler.
---
gcc/config/rs6000/rs6000.h | 1 +
1 file changed, 1 insertion(+)
diff
This patch defines _ARCH_PWR_FUTURE if -mcpu=future was used.
2024-02-14 Michael Meissner
gcc/
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
_ARCH_PWR_FUTURE if -mcpu=future.
---
gcc/config/rs6000/rs6000-c.cc | 2 ++
1 file changed, 2 insertions(+)
diff
This patch prints that -mcpu=future was selected if you use the debugging
switch -mdebug=reg.
2024-02-14 Michael Meissner
gcc/
* config/rs6000/rs6000.cc (rs6000_opt_masks): Add entry to print out
-mfuture in the isa flags.
---
gcc/config/rs6000/rs6000.cc | 1 +
1 file
This patch adds the basic support for -mcpu=future, which is a framework to add
support for possible future PowerPCs. This patch is only sets the future bit
in the ISA options.
Can I check this into GCC 15 when it opens up, and immediately back port it to
GCC 14 after GCC 14.0 is released?
This series of patches takes the first 2 patches from the dense math patches to
add the support for -mcpu=future.
If these patches are approved, I will re-base the rest of the dense math
patches off of these patches.
While patch #1 of the series was fairly self contained, in that it added the
The constraints "i" and "s" can be used with a symbol that binds
externally, e.g.
```
namespace ns { extern int var, a[4]; }
void foo() {
asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "s"(::var));
asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(::a[3]));
}
```
gcc/testsuite/ChangeLog:
Hi Jeff,
I don't have permission to commit, can you push it for me? If you look good
to you.
> Jeff Law 於 2024年2月14日 凌晨12:03 寫道：
>
>
>
>> On 2/4/24 20:20, Monk Chiang wrote:
>> gcc/ChangeLog:
>> PR target/113742
>> * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
>>
Hi Jeff,
I don't have permission to commit, can you push it for me? If you look good
to you.
> Jeff Law 於 2024年2月14日 凌晨12:03 寫道：
>
>
>
>> On 2/4/24 20:20, Monk Chiang wrote:
>> gcc/ChangeLog:
>>PR target/113742
>>* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
>>
On 2/13/24 20:34, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 06:08:42PM -0500, Jason Merrill wrote:
On 2/11/24 08:26, Nathaniel Shead wrote:
Currently inline vars imported from modules aren't correctly finalised,
which means that import_export_decl gets called at the end of TU
processing
On 2/13/24 18:20, Nathaniel Shead wrote:
On Tue, Feb 13, 2024 at 06:12:51PM -0500, Jason Merrill wrote:
On 2/11/24 21:26, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This ensures that with modules enabled, redeclaring an enum in the wrong
On 2/10/24 22:54, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just modules.exp and dg.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
(Also I noticed I forgot to add the PR to the changelog in my last
patch, I've fixed that locally.)
-- >8 --
After fixing
On Tue, Feb 13, 2024 at 06:08:42PM -0500, Jason Merrill wrote:
> On 2/11/24 08:26, Nathaniel Shead wrote:
> >
> > Currently inline vars imported from modules aren't correctly finalised,
> > which means that import_export_decl gets called at the end of TU
> > processing despite not being meant to
Following a mail exchange with Jonathan back in December; finally
implementing what we discussed/he confirmed.
Gerald
libstdc++-v3:
* doc/xml/manual/status_cxx2023.xml: Fix C++ item p2442 to be
version 1.
* doc/html/manual/status.html: Regenerate.
---
Pushed.
Gerald
---
htdocs/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index ed505637..032cc4b6 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -55,7 +55,7 @@ mission statement.
News
This follows a web server redirect.
Gerald
gcc:
* doc/install.texi (Prerequisites): Update gettext link.
---
gcc/doc/install.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index c7794439107..173233096d1 100644
On 2/10/24 17:57, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should I re-introduce the tree checking and just add checks for the
new kinds of declarations that could be have keyed decls?
This way is fine.
-- >8 --
The fix for PR107398
Note that is not part of current HTML standards; can we simply
remove it?
Gerald
---
htdocs/gcc-14/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6ac7c8b1..92bd0a7b 100644
---
In addition, I believe it might be good to rephrase that sentence. Do you
mean "the linker will not pull in that code from ... any more"?
Gerald
---
htdocs/gcc-14/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html
The error message is not clear what options are being taked about when it says
the values
need to match; plus there is a wrong quotation dealing with the diagnostic.
So this changes the error message to be exactly talking about the param options
that
are being taked about and now with the
On Tue, Feb 13, 2024 at 06:12:51PM -0500, Jason Merrill wrote:
> On 2/11/24 21:26, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > This ensures that with modules enabled, redeclaring an enum in the wrong
> > module or with the
On 2/11/24 21:26, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.
The patch also rearranges the order of the
On 2/11/24 08:26, Nathaniel Shead wrote:
Currently inline vars imported from modules aren't correctly finalised,
which means that import_export_decl gets called at the end of TU
processing despite not being meant to for these kinds of declarations.
I disagree that it's not meant to; inline
On 2/13/24 17:59, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
A minimal fix to quash an extra ; warning. I have a more complete
patch for GCC 15.
DR 1693
PR c++/113760
gcc/cp/ChangeLog:
* parser.cc
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
A minimal fix to quash an extra ; warning. I have a more complete
patch for GCC 15.
DR 1693
PR c++/113760
gcc/cp/ChangeLog:
* parser.cc (cp_parser_member_declaration): Only pedwarn about an extra
On 2/13/24 15:52, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 03:41:53PM -0500, Jason Merrill wrote:
On 2/13/24 14:43, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
Sadly, I must admit this
On 2/13/24 11:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
both of these fixes OK for trunk?
-- >8 --
Here during ahead of time checking of the non-dependent new-expr we
synthesize B's copy constructor, which should be defined as deleted
due to A's
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
The vect testsuite will chose the dg-do default based on if it knows the
running target does not support running with the vector extensions enabled
(for easy of testing). The problem is when it is decided the default is compile
instead of run, dg-additional-sources does not work. So the fix is to
Since push2/pop2 requires 16-byte stack alignment, don't generate them
if the incoming stack isn't 16-byte aligned.
gcc/
PR target/113912
* config/i386/i386.cc (ix86_can_use_push2pop2): New.
(ix86_pro_and_epilogue_can_use_push2pop2): Use it.
(ix86_emit_save_regs):
On Tue, Feb 13, 2024 at 03:41:53PM -0500, Jason Merrill wrote:
> On 2/13/24 14:43, Marek Polacek wrote:
> > On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
> > > On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
> > > > Sadly, I must admit this is looking like GCC 15
On 2/13/24 14:43, Marek Polacek wrote:
On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
Sadly, I must admit this is looking like GCC 15 material.
If deferred for GCC 15, can't we at least do some minimal
change and
On Tue, Feb 13, 2024 at 02:43:39PM -0500, Marek Polacek wrote:
> On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
> > On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
> > > Sadly, I must admit this is looking like GCC 15 material.
> >
> > If deferred for GCC 15, can't
On 2/13/24 05:27, Rainer Orth wrote:
Hi Jason,
On 2/2/24 10:23, Rainer Orth wrote:
c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:
FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr
Hi Jakub,
Jakub Jelinek wrote:
Of course it makes me wonder to what extent we actually do support the
OpenMP 5.1 target_device device_num trait with constant or non-constant
device num:
Answer: If one removes some early errors such that the compiler
continues a bit further, one gets:
36 |
On Tue, Feb 13, 2024 at 11:58:00AM -0800, H.J. Lu wrote:
> Since push2/pop2 requires 16-byte stack alignment, don't use them if the
> incoming stack isn't 16-byte aligned.
>
> gcc/
>
> PR target/113876
> * config/i386/i386.cc (ix86_pro_and_epilogue_can_use_push2pop2):
> Return
Since push2/pop2 requires 16-byte stack alignment, don't use them if the
incoming stack isn't 16-byte aligned.
gcc/
PR target/113876
* config/i386/i386.cc (ix86_pro_and_epilogue_can_use_push2pop2):
Return false if the incoming stack isn't 16-byte aligned.
gcc/testsuite/
On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
> > Sadly, I must admit this is looking like GCC 15 material.
>
> If deferred for GCC 15, can't we at least do some minimal
> change and just guard the member pedwarn
On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote:
> Sadly, I must admit this is looking like GCC 15 material.
If deferred for GCC 15, can't we at least do some minimal
change and just guard the member pedwarn with cxx_dialect < something?
Given that -Wextra-semi isn't on by default
Am 13.02.24 um 19:13 schrieb Harald Anlauf:
indeed the new testcase just regressed due to commit
r14-8947-g6caec7d9ec37e6 ... :-(
Reduced testcase which fails on trunk:
program p
implicit none
integer, parameter :: n = 100, l = 10
character(l) :: a = 'a234567890', b(n) = 'bcdefghijk'
Sadly, I must admit this is looking like GCC 15 material.
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
Prompted by c++/113760, I started looking into a bogus "extra ;"
warning in C++14. It quickly turned out that if I want to fix
this for good, the fix will not be so small.
This
David: Ping.
On Tue, 2024-02-06 at 07:54 -0500, Antoni Boucher wrote:
> David: Ping.
>
> On Tue, 2024-01-30 at 10:50 -0500, Antoni Boucher wrote:
> > David: I'm unsure what to do here. It seems we cannot find a
> > reviewer.
> > Would it help if I show you the code in gccrs that is similar?
> >
Hi Steve,
Am 13.02.24 um 18:21 schrieb Steve Kargl:
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote:
Dear all,
the attached patch fixes a mis-handling of optional dummy arguments
passed to optional dummy arguments of procedures with the bind(c)
attribute. When those procedures
On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Believe it or not, even though I have re-worked the internals of the
>> lattices completely, the array itself is older than my involvement with
>> GCC (or at least with ipa-cp.c ;-).
>>
>> So it being an array and not a vector is historical coincidence,
On Tue, Feb 13, 2024 at 06:31:02PM +0100, Tobias Burnus wrote:
> PR middle-end/113904
>
> gcc/c/ChangeLog:
>
> * c-parser.cc (c_parser_omp_context_selector): Handle splitting of
> OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
>
> gcc/cp/ChangeLog:
>
>
Jakub Jelinek wrote:
Isn't all this caused just by the missing check that condition trait has a
constant expression?
IMHO that is the way to handle it in GCC 14.
Concur – how about the following patch?
Tobias
PS: See PR113904 for follow up tasks. / Instead of '.AND.' etc. I could
have also
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes a mis-handling of optional dummy arguments
> passed to optional dummy arguments of procedures with the bind(c)
> attribute. When those procedures are expecting CFI descriptors,
> there is no
Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
both of these fixes OK for trunk?
-- >8 --
Here during ahead of time checking of the non-dependent new-expr we
synthesize B's copy constructor, which should be defined as deleted
due to A's inaccessible copy constructor. But
On Tue, Feb 13, 2024 at 08:40:52AM -0800, H.J. Lu wrote:
> Add x32 and IBT support to x86 heap trampoline implementation with a
> testcase.
>
> 2024-02-13 Jakub Jelinek
> H.J. Lu
>
> libgcc/
>
> PR target/113855
> * config/i386/heap-trampoline.c (trampoline_insns):
Add x32 and IBT support to x86 heap trampoline implementation with a
testcase.
2024-02-13 Jakub Jelinek
H.J. Lu
libgcc/
PR target/113855
* config/i386/heap-trampoline.c (trampoline_insns): Add IBT
support and pad to the multiple of 4 bytes. Use movabsq
On 2/6/24 10:38, Edwin Lu wrote:
This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains
* https://github.com/riscv/riscv-b/tags
gcc/ChangeLog:
*
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
If register_specialization finds a previous declaration and throws the new
one away, we shouldn't still add the new one to
DECL_TEMPLATE_SPECIALIZATIONS.
PR c++/113612
gcc/cp/ChangeLog:
* pt.cc
On 2/7/24 17:30, Patrick O'Neill wrote:
There is a proposal to split the A extension into two parts: Zaamo and Zalrsc.
This patch adds basic support by making the A extension imply Zaamo and
Zalrsc.
Proposal: https://github.com/riscv/riscv-zaamo-zalrsc/tags
gcc/ChangeLog:
*
On 2/13/24 01:21, Jakub Jelinek wrote:
Hi!
This is IMHO more of a theoretical case, I believe my current code
doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of
int, long int or long long int. For size_t and %zd or %zi I'm
using va_arg (whatever, ssize_t) and hope that
On 2/13/24 01:26, Jakub Jelinek wrote:
On Mon, Feb 12, 2024 at 04:10:33PM +, Joseph Myers wrote:
On Sat, 10 Feb 2024, Jakub Jelinek wrote:
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
On 2/13/24 06:42, Robin Dapp wrote:
Hi,
scalar loads provide offset addressing while unit-stride vector
instructions cannot. The offset must be loaded into a general-purpose
register before it can be used. In order to account for this, this
patch adds an address arithmetic heuristic that
On 2/4/24 20:20, Monk Chiang wrote:
gcc/ChangeLog:
PR target/113742
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr113742.c: New test.
I was going
On 2/9/24 09:53, Palmer Dabbelt wrote:
This builds for me, and I frequently have python-is-python3 type
packages installed so I think I've been implicitly testing it for a
while. Looks like Kito's tested similar configurations, and the
bugzilla indicates we should be moving over.
On 13/02/2024 10:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
The alternative approach (that is changing the result a bit) is to drop
the special treatment for arm*-*-*. I'm not sure if this is prefered or
just disable the test for incompatible flags for arm*-*-*.
--
The
On Tue, Feb 13, 2024 at 10:42:52AM +0100, Jakub Jelinek wrote:
> On Sat, Feb 10, 2024 at 10:05:34AM -0800, H.J. Lu wrote:
> > > I bet it probably doesn't work properly for -mx32 (which defines
> > > __x86_64__), CCing H.J. on that, but that is a preexisting issue
> > > (and I don't have any
On Tue, Feb 13, 2024 at 03:54:28PM +0100, Tobias Burnus wrote:
> Inomp_resolve_declare_variant, a code path generates a new decl for the base
> function – in doing so, it ignores the assembler name. As the included
> Fortran example shows, this will lead to a linker error. Solution: Also copy
>
Inomp_resolve_declare_variant, a code path generates a new decl for the
base function – in doing so, it ignores the assembler name. As the
included Fortran example shows, this will lead to a linker error.
Solution: Also copy over the assembler name. Comments, suggestions,
remarks before I
Hi,
scalar loads provide offset addressing while unit-stride vector
instructions cannot. The offset must be loaded into a general-purpose
register before it can be used. In order to account for this, this
patch adds an address arithmetic heuristic that keeps track of data
reference operands.
The recent enhancement to discover constant array indices by range
info used by get_ref_base_and_extent doesn't work when the outermost
component reference is to a bitfield because we track the running
offset in the reference ops as bytes. The following does as
ao_ref_init_from_vn_reference and
The SLP permute optimization rewrite fixed this.
Tested on x86_64-unknown-linux-gnu, pushed to trunk and 13 branch.
PR tree-optimization/113896
* g++.dg/torture/pr113896.C: New testcase.
---
gcc/testsuite/g++.dg/torture/pr113896.C | 35 +
1 file changed,
On 2024-02-12 10:00, Richard Biener wrote:
GCC driver support is then to the extent identifying the inputs and the outputs.
We already have -MM to generate a list of non-system dependencies, so
gcc should be able to pass on inputs to the tool, which could then map
those files (and the system
Rainer Orth writes:
> As it turned out, my patch to complete the libgm2 autoconf macros works
> on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:
>
> /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
> m2iso_wraptime_gettimeofday(void*, timezone*)':
Pushed.
PR tree-optimization/113831
* tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Fix
typo in comment.
---
gcc/tree-ssa-sccvn.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index
The following adjusts move_early_exit_stmts to track the last seen
VUSE instead of getting it from the last store which could be a PHI
where gimple_vuse doesn't work.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113902
* tree-vect-loop.cc
Ok for trunk and releases/gcc-13?
The alternative approach (that is changing the result a bit) is to drop
the special treatment for arm*-*-*. I'm not sure if this is prefered or
just disable the test for incompatible flags for arm*-*-*.
--
The test assumes it's okay to supply
On Tue, 13 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> When doing early break vectorization we should treat the final iteration as
> possibly being partial. This so that when we calculate the vector loop upper
> bounds we take into account that final iteration could have done some work.
>
>
The following fixes a missing add to the accumulated offset when
adjusting an ARRAY_REF op for value-ranges applied to by
get_ref_base_and_extent.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113898
* tree-ssa-sccvn.cc
Hi All,
When doing early break vectorization we should treat the final iteration as
possibly being partial. This so that when we calculate the vector loop upper
bounds we take into account that final iteration could have done some work.
The attached testcase shows that if we don't then cunroll
As it turned out, my patch to complete the libgm2 autoconf macros works
on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_gettimeofday(void*, timezone*)':
Hi Jason,
> On 2/2/24 10:23, Rainer Orth wrote:
>> c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:
>> FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr
>> FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr
>> FAIL:
On Sat, Feb 10, 2024 at 10:05:34AM -0800, H.J. Lu wrote:
> > I bet it probably doesn't work properly for -mx32 (which defines
> > __x86_64__), CCing H.J. on that, but that is a preexisting issue
> > (and I don't have any experience with it; I guess one would either
> > need to add 4 bytes of
On Tue, 13 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> As I wrote earlier, I was seeing
> FAIL: gcc.dg/torture/bitint-24.c -O0 execution test
> FAIL: gcc.dg/torture/bitint-24.c -O2 execution test
> with the ia32 _BitInt enablement patch on i686-linux. I thought
> floatbitintxf.c was
On Tue, 13 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
> as broke the gengtype on i686-linux before the libiberty fix is certainly
> unexpected. size_t is there unsigned int, so expected fmt_size_t is
> unsigned int (or some other
On Mon, 12 Feb 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> > I've committed this patch
>
> ... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
> "amdgcn: add -march=gfx1030 EXPERIMENTAL".
>
> The RDNA2 ISA variant doesn't support certain
On Mon, Feb 12, 2024 at 04:10:33PM +, Joseph Myers wrote:
> On Sat, 10 Feb 2024, Jakub Jelinek wrote:
>
> > * c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
> > (PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
> > z modifiers.
>
> Please also add
Hi!
This is IMHO more of a theoretical case, I believe my current code
doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of
int, long int or long long int. For size_t and %zd or %zi I'm
using va_arg (whatever, ssize_t) and hope that ssize_t is the signed
type corresponding to
Hi!
As I wrote earlier, I was seeing
FAIL: gcc.dg/torture/bitint-24.c -O0 execution test
FAIL: gcc.dg/torture/bitint-24.c -O2 execution test
with the ia32 _BitInt enablement patch on i686-linux. I thought
floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it
turned
84 matches
Mail list logo
