https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111078
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
For the following immediate load operation in
gcc/testsuite/gcc.target/loongarch/imm-load1.c:
long long r = 0x0101010101010101;
Before this patch:
lu12i.w $r15,16842752>>12
ori $r15,$r15,257
lu32i.d $r15,0x10101>>32
lu52i.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
--- Comment #3 from Andrew Pinski ---
-1/~0 has the same issue as mentioned:
```
int finv(int a, int b, int c, int d)
{
return (a == 2 ? -1 : b) + (c == 3 ? -1 : d);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
The patch is coming along, I just have a quick question regarding
style. I make use of IILE's (immediately invoked lambda expression) a
whole lot in my own code. I know that their use is controversial in
general so I would prefer to ask instead of just submitting the patch
using them a bunch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112416
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112519
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #5 from Andrew Pinski ---
Works for me with r14-5566-g841008d3966c0f .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #1 from Andrew Pinski ---
This code seems to originally was added with
https://gcc.gnu.org/pipermail/gcc-patches/2011-April/311365.html
The discussion on the patch continues into May:
Because the XTheadVector extension does not support fractional
operations, so we need to delete the related intrinsics.
The types involved are as follows:
v(u)int8mf8_t,
v(u)int8mf4_t,
v(u)int8mf2_t,
v(u)int16mf4_t,
v(u)int16mf2_t,
v(u)int32mf2_t,
vfloat16mf4_t,
vfloat16mf2_t,
vfloat32mf2_t
This patch involves the generation of xtheadvector special
load/store instructions.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for ternary and unary operations.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/testsuite/ChangeLog:
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/testsuite/ChangeLog:
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/testsuite/ChangeLog:
This patch is to handle the differences in instruction generation
between vector and xtheadvector, mainly adding th. prefix
to all xtheadvector instructions.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/ChangeLog:
* config.gcc: Add header for
This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph Müllner
gcc/ChangeLog:
*
This patch series presents gcc implementation of the XTheadVector
extension [1].
[1] https://github.com/T-head-Semi/thead-extension-spec/
I updated my patch series, because I forgot to add co-authors in
the last version.
Contributors:
Jun Sha (Joshua)
Jin Ma
Christoph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #10 from Andrew Pinski ---
I have a patch but I don't like it since it requires to touch
gimple-if-to-switch.cc since that uses init_range_entry. Maybe someone else
can come up with a better patch.
LGTM, that's a really great clean up :)
On Sat, Nov 18, 2023 at 11:12 AM Juzhe-Zhong wrote:
>
> This patch refactors RVV iteratros for easier maintain.
>
> E.g.
>
> (define_mode_iterator V [
> RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI
> "TARGET_MIN_VLEN > 32")
>
> RVVM8HI
Use no suffix at all in the musl dynamic linker name for hard
float ABI. Use -sf and -sp suffixes in musl dynamic linker name
for soft float and single precision ABIs. The following table
outlines the musl interpreter names for the LoongArch64 ABI names.
musl interpreter| LoongArch64
This patch refactors RVV iteratros for easier maintain.
E.g.
(define_mode_iterator V [
RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI "TARGET_MIN_VLEN
> 32")
RVVM8HI RVVM4HI RVVM2HI RVVM1HI RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > 32")
(RVVM8HF "TARGET_VECTOR_ELEN_FP_16")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
---
On Thu, Nov 16, 2023 at 8:42 AM Dmitry Antipov wrote:
>
> (The following sample is taken from my LKML post at
> https://lkml.org/lkml/2023/11/15/213)
>
> $ cat t-build-bug.c
>
> struct vring_tx_mac {
> unsigned int d[3];
> unsigned int ucode_cmd;
> } __attribute__((packed));
>
>
This patch implements a new analyzer warning: -Wanalyzer-infinite-loop.
It works by examining the exploded graph once the latter has been
fully built. It attempts to detect cycles in the exploded graph in
which:
- no externally visible work occurs
- no escape is possible from the cycle once it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:841008d3966c0fe7a80ec10703a50fbdab7620ac
commit r14-5566-g841008d3966c0fe7a80ec10703a50fbdab7620ac
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588
Nathaniel Shead changed:
What|Removed |Added
CC||nathanieloshead at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-18
The following functions invoke signed integer overflow (UB) for some extreme
values of days and months [1]:
weekday operator+(const weekday& x, const days& y); // #1
month operator+(const month& x, const months& y); // #2
For #1 the problem is that in libstdc++ days::rep is int64_t. Other
weekday operator+(const weekday& x, const days& y); // #1
month operator+(const month& x, const months& y); // #2
For #1 the problem is that in libstdc++ days::rep is int64_t. Other
implementations use int32_t and cast operands to int64_t. Hence then perform
arithmetic operations without
>> I suspect it's going to be even worse if you we have multiple patterns
>> with the same underlying RTL, but just different output strings.
No. We don't need to add (duplicate) any new patterns.
I know RVV GCC very well. I know how to do that.
juzhe.zh...@rivai.ai
From: Jeff Law
Date:
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do is prefix the instruction
with "th.".
No. I don't think we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #9 from Andrew Pinski ---
Adding -fdisable-tree-reassoc2 causes the problem not to happen so yes it is a
bug in reassoc. If I get some time next week I will look into adding the
support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #8 from Andrew Pinski ---
tree-ssa-reassoc.cc needs to call mark_ssa_maybe_undefs and checks
ssa_name_maybe_undef_p similar to the way tree-ssa-ifcombine.cc does it.
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
>> may also need to add '^' to the punct_valid_p hook. But yes, this is
>> the preferred way to go when all we need to do is prefix the instruction
>> with "th.".
No. I don't think we need to add '^' . I don't want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #7 from Andrew Pinski ---
Wait a minute, h might be uninitialized.
So the issue is inside reassociate which is must not have recognized that
iftmp.7_30 is defined by a maybe an uninitialized variable ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #6 from Andrew Pinski ---
forwprop3 does:
```
_12 = ~iftmp.7_30;
h_40 = (unsigned int) _12;
...
if (h_40 == 4294967295)
```
into:
```
_75 = (unsigned int) iftmp.7_30;
if (iftmp.7_30 == 0)
```
Which as far as I can tell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603
--- Comment #1 from Antoni ---
Created attachment 56628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56628=edit
Patch
Hi.
This adds functions to set the personality function (bug 112603).
I'm not sure I can make a test for this: it seems the personality
function will not be set if there are no try/catch inside the
functions.
Do you know a way to keep the personality function that is set in this
case?
Or should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603
Bug ID: 112603
Summary: Allow setting the personality function
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #5 from Andrew Pinski ---
Looking into what is going wrong.
Snapshot gcc-12-20231117 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231117/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112602
--- Comment #1 from Antoni ---
Created attachment 56627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56627=edit
Patch
Hi.
This patch adds a vector permutation and vector access operations (bug
112602).
This was split from this patch:
https://gcc.gnu.org/pipermail/jit/2023q1/001606.html
Thanks for the review.
From 25b386334f22845d7ba1b60658730373eb6ddbb3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Known to fail|
Hello-
I often find it convenient to run a new c-c++-common test from the
main build dir like:
$ make -j 2 RUNTESTFLAGS=dg.exp=new-test.c check-gcc-{c,c++}
I noticed that sometimes this produces a corrupted site.exp and then no
tests work until it is remade manually. To avoid the issue, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112602
Bug ID: 112602
Summary: Support vector permutation and access
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112596
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-17
On Fri, 17 Nov 2023 at 15:32, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> GCC generates better code for add_sat if we use:
>
> unsigned z = x + y;
> z |= -(z < x);
> return z;
>
> If the compiler can't be improved we should consider using that instead
> of
ibsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231117 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106650
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement (part of?) P2280, Using unknown
pointers and references in constant expressions. (Note that R4 seems to
only allow References to unknown/Accesses via this, but not Pointers to
unknown.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #2 from Jonathan Wakely ---
For similar saturating subtraction functions:
unsigned
sub_sat(unsigned x, unsigned y) noexcept
{
unsigned z;
if (!__builtin_sub_overflow(x, y, ))
return z;
return 0;
}
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #1 from Jonathan Wakely ---
Similar results for aarch64 with GCC:
add_sat(unsigned int, unsigned int):
addsw0, w0, w1
bcs .L7
ret
.L7:
mov w0, -1
ret
add_sat2(unsigned int,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
Bug ID: 112600
Summary: Failed to optimize saturating addition using
__builtin_add_overflow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
--- Comment #1 from Patrick O'Neill ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #1 from Patrick O'Neill ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
--- Comment #1 from Patrick O'Neill ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
--- Comment #1 from Patrick O'Neill ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
Bug ID: 112599
Summary: RISC-V regression testsuite errors with
rv64gcv_zvl1024b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
Bug ID: 112598
Summary: RISC-V regression testsuite errors with
rv64gcv_zvl512b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
Bug ID: 112597
Summary: RISC-V regression testsuite errors with
rv64gcv_zvl256b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
On 11/17/23 14:08, Antoni Boucher wrote:
In contrast with the other frontends, libgccjit can be executed
multiple times in a row in the same process.
Yup. I'm aware of that. Even so calling init_emit_once more than one
time still seems wrong.
jeff
In contrast with the other frontends, libgccjit can be executed
multiple times in a row in the same process.
This is the source of multiple bugs due to global variables as can be
seen by several patches I sent these past years.
On Fri, 2023-11-17 at 14:06 -0700, Jeff Law wrote:
>
>
> On
On 11/16/23 15:36, Antoni Boucher wrote:
Hi.
This patch fixes a RTL bug when using some target-specific builtins in
libgccjit (bug 112576).
The test use a function from an unmerged patch:
https://gcc.gnu.org/pipermail/jit/2023q1/001605.html
Thanks for the review!
The natural question here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112578
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
The usage LSX and LASX frint/ftint instructions had some problems:
1. These instructions raises FE_INEXACT, which is not allowed with
-fno-fp-int-builtin-inexact for most C2x section F.10.6 functions
(the only exceptions are rint, lrint, and llrint).
2. The "frint" instruction without
* config/loongarch/loongarch-def.h:
(loongarch_isa_base_features): Declare. Define it in ...
* config/loongarch/loongarch-cpu.cc
(loongarch_isa_base_features): ... here.
(fill_native_cpu_config): If we know the base ISA of the CPU
model from PRID,
With -mdiv32, we can assume div.w[u] and mod.w[u] works on low 32 bits
of a 64-bit GPR even if it's not sign-extended.
gcc/ChangeLog:
* config/loongarch/loongarch.md (DIV): New mode iterator.
(3): Don't expand if TARGET_DIV32.
(di3_fake): Disable if TARGET_DIV32.
gcc/ChangeLog:
* config/loongarch/genopts/isa-evolution.in: (lam-bh, lamcas):
Add.
* config/loongarch/loongarch-str.h: Regenerate.
* config/loongarch/loongarch.opt: Regenerate.
* config/loongarch/loongarch-cpucfg-map.h: Regenerate.
*
This option (CPUCFG word 0x3 bit 23) means "the hardware guarantee that
two loads on the same address won't be reordered with each other". Thus
we can omit the "load-load" barrier dbar 0x700.
This is only a micro-optimization because dbar 0x700 is already treated
as nop if the hardware supports
LoongArch v1.10 introduced the concept of ISA evolution. During ISA
evolution, many independent features can be added and enumerated via
CPUCFG.
Add a data file into genopts storing the CPUCFG word, bit, the name
of the command line option controlling if this feature should be used
for
On LA664, the PRID preset is ISA_BASE_LA64V110 but the base architecture
is guessed ISA_BASE_LA64V100. This causes a warning to be outputed:
cc1: warning: base architecture 'la64' differs from PRID preset '?'
But we've not set the "?" above in loongarch_isa_base_strings, thus it's
a nullptr
Superseds
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636795.html.
Requires
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636946.html.
Changes:
- Rebase on top of "Add LoongarchV1.1 instructions support".
- Not to translate loongarch-def.c C++. Use int64_t instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112596
Bug ID: 112596
Summary: GCC regex error in
Product: gcc
Version: 9.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112552
--- Comment #8 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e
commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e
Author: Robin Dapp
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #12 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e
commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e
Author: Robin Dapp
Date: Thu
Replaces "lto_priv.$clone_number" by
"lto_priv.$partition_hash.$partition_specific_clone_number".
To reduce divergence for incremental LTO.
Bootstrapped/regtested on x86_64-pc-linux-gnu
gcc/lto/ChangeLog:
* lto-partition.cc (set_clone_partition_name_checksum): New.
This patch squashes order of symbols in individual partitions, so that
their relative order is conserved, but is not influenced by symbols in
other partitions.
Order of cloned symbols is set to 0. This should be fine because order
specifies order of symbols in input files, which cloned symbols are
This patch implements new cache partitioning. It tries to keep symbols
from single source file together to minimize propagation of divergence.
It starts with symbols already grouped by source files. If reasonably
possible it only either combines several files into one final partition,
or, if a
This patch implements lockfile used for incremental LTO.
Bootstrapped/regtested on x86_64-pc-linux-gnu
gcc/ChangeLog:
* Makefile.in: Add lockfile.o.
* lockfile.cc: New file.
* lockfile.h: New file.
---
gcc/Makefile.in | 5 +-
gcc/lockfile.cc | 136
This patch implements Incremental LTO as ltrans cache.
The cache is active when directory $GCC_LTRANS_CACHE is specified and exists.
Stored are pairs of ltrans input/output files and input file hash.
File locking is used to allow multiple GCC instances to use to same cache.
Bootstrapped/regtested on x86_64-pc-linux-gnu
gcc/ChangeLog:
* lto-streamer.cc (lto_get_section_name): Remove random_seed in WPA.
---
gcc/lto-streamer.cc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/lto-streamer.cc b/gcc/lto-streamer.cc
index
Bootstrapped/regtested on x86_64-pc-linux-gnu
gcc/ChangeLog:
* lto-opts.cc (lto_write_options): Skip OPT_fltrans_output_list_.
---
gcc/lto-opts.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/lto-opts.cc b/gcc/lto-opts.cc
index c9bee9d4197..0451e290c75 100644
---
Hi,
these patches implement Incremental LTO, specifically by caching results of
ltrans phase. Secondarily these patches contain changes to reduce divergence of
ltrans partitions so that they can be cached.
The aim is to reduce compile times for quick edit-compile cycles while using
LTO. Even with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112584
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112590
--- Comment #3 from Janez Zemva ---
Sorry for my last comment. I have prepared a more involved example:
https://github.com/user1095108/ca/blob/master/consttests.cpp
If
test();
is commented out, everything compiles, otherwise not.
> No, you shouldn't place _7 != 0 inside the .COND_ADD but instead
> have an extra pattern stmt producing that so
>
> patt_8 = _7 != 0;
> patt_9 = .COND_ADD (patt_8, ...);
>
> that's probably still not enough, but I always quickly forget how
> bool patterns work ... basically a comparison like
Hi Tobias,
On 11/17/23 12:38, Tobias Burnus wrote:
Hi Harald, hi all,
On 16.11.23 20:30, Harald Anlauf wrote:
According to the standard one can have 99 lines with only
"&" and then an ";", but then only 100 lines with 1 characters.
I believe a single '&' is not valid, you either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112590
--- Comment #2 from Janez Zemva ---
Very nice, but if I write:
int main()
{
static constexpr S<10> s;
return 0;
}
there will still be a compile error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112589
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112590
Mital Ashok changed:
What|Removed |Added
CC||mital at mitalashok dot co.uk
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112595
Bug ID: 112595
Summary: ICE on invalid code: Literal class NTTP aggregate
initialized with self-referential pointer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
SME2 adds a 512-bit lookup table called ZT0. It is enabled
and disabled by PSTATE.ZA, just like ZA itself. This patch
adds support for the register, including saving and restoring
contents.
The code reuses the V8DI that was added for LS64, including
the associated memory classification rules.
Some SME2 instructions interpret predicates as counters, rather than
as bit-per-byte masks. The SME2 ACLE defines an svcount_t type for
this interpretation.
I don't think we have a better way of representing counters than
the VNx16BI that we use for masks. The patch therefore doesn't
add a new
SME2 has some instructions that operate on pairs of predicates.
The SME2 ACLE defines an svboolx2_t type for the associated
intrinsics.
The patch uses a double-width predicate mode, VNx32BI, to represent
the contents, similarly to how data vector tuples work. At present
there doesn't seem to be
gcc/
* doc/invoke.texi: Document +sme2.
* doc/sourcebuild.texi: Document aarch64_sme2.
* config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION):
Add sme2.
* config/aarch64/aarch64.h (AARCH64_ISA_SME2, TARGET_SME2): New macros.
gcc/testsuite/
Am Fr., 17. Nov. 2023 um 18:31 Uhr schrieb Jonathan Wakely :
>
> On Fri, 17 Nov 2023 at 17:01, Daniel Krügler
> wrote:
> >
[..]
> > > +
> > > +namespace std _GLIBCXX_VISIBILITY(default)
> > > +{
> > > +_GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > +
> > > + /// Add two integers, with saturation in
1 - 100 of 283 matches
Mail list logo
