gcc:
PR target/69374
* doc/install.texi (Specific) <*-*-cygwin>: Update web link.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 621c874d268..165d48c02f8 100644
--- a/gcc/doc/install.tex
On Tue, 11 Jun 2024, Richard Sandiford wrote:
> Don't think it makes any difference, but:
>
> Richard Biener writes:
> > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo,
> > stmt_vec_info stmt_info,
> > access excess elements.
> > ??? Enhance
On Wed, 12 Jun 2024, 02:14 Alexandre Oliva, wrote:
>
> Tests involving float128_t were xfailed or otherwise worked around for
> vxworks on aarch64. The same issue came up on rtems. This patch
> adjusts them similarly.
>
> Regstrapping on x86_64-linux-gnu. Also tested with gcc-13 on
> aarch64-r
On Wed, 12 Jun 2024, 02:17 Alexandre Oliva, wrote:
>
> Some c++23 tests fail on targets that don't satisfy dg-require-cmath,
> because referenced math functions don't get declared in std.
Are they present on the target at all? Is not declaring them in std the
underlying bug here?
Add the
>
Hi Edwin,
this LGTM but I just remembered I intended to turn the assert
into a more descriptive error.
The attached patch has been sitting on my local branch for a
while. Maybe we should rather fold yours into it?
Regards
Robin
>From d164403ef577917f905c1690f2199fab330f05e2 Mon Sep 17 00:00:0
Hi Edwin,
this is OK but did you check if we can get rid of the subreg
condition now that we have gen_lowpart?
Regards
Robin
This is a left-over that redirects to our main page; we removed all
our Java material years ago.
---
htdocs/news.html | 1 -
1 file changed, 1 deletion(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index de92bdf6..4a24a4ad 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -1799,7 +179
Hi,
on 2023/2/10 10:59, Xionghu Luo wrote:
> Resend this patch...
>
> v4: Update per comments.
> v3: rename altivec_vmrghb_direct_le to altivec_vmrglb_direct_le to match
> the actual output ASM vmrglb. Likewise for all similar xxx_direct_le
> patterns.
> v2: Split the direct pattern to be and le
HAO CHEN GUI writes:
> Hi,
> This patch replaces rtx_cost with insn_cost in forward propagation.
> In the PR, one constant vector should be propagated and replace a
> pseudo in a store insn if we know it's a duplicated constant vector.
> It reduces the insn cost but not rtx cost. In this case, t
> Hmm, ok. The bit that confused me most was:
>
> if (last_needs_comparison != -1)
> {
> end_sequence ();
> start_sequence ();
> ...
> }
>
> which implied that the second attempt was made conditionally.
> It seems like it's always used and is an inherent part of the
>
On Tue, Jun 11, 2024 at 11:21 AM Arthur Cohen wrote:
>
> Thanks Richi!
>
> Tested again and pushed on trunk.
This patch introduced a couple of errors during ./configure:
checking for library containing dlopen... none required
checking for library containing pthread_create... none required
/git/
Hey,
> On Jun 12, 2024, at 00:27, René Rebe wrote:
>
> Hi!
>
>> On Jun 12, 2024, at 00:15, Segher Boessenkool
>> wrote:
>>
>> Hi!
>>
>> What does "powerpc < 7" mean? Something before POWER ISA 2.06?
>
> PowerPC ISA level 7 or whatever you like to call it.
>
>> On Tue, Jun 11, 2024 at 04:
Victor Do Nascimento writes:
> Changes in V2:
>
> As explained in patch v2 1/4, it has become clear that the current
> approach of querying assembler support for newer architectural
> extensions at compile time is undesirable both from a maintainability
> as well as a consistency standpoint - Diff
On 06/06/2024 12:53, Richard Earnshaw (lists) wrote:
On 05/06/2024 17:07, Andre Vieira (lists) wrote:
Hi,
This patch adds missing assembly directives to the CMSE library wrapper to call
functions with attribute cmse_nonsecure_call. Without the .type directive the
linker will fail to produ
Andrew Pinski writes:
> Bitreverse rtl code was added with r14-1586-g6160572f8d243c. So let's
> use it instead of an unspec. This is just a small cleanup but it does
> have one small fix with respect to rtx costs which didn't handle vector modes
> correctly for the UNSPEC and now it does.
> This i
On Wed, 12 Jun 2024, Richard Biener wrote:
> On Tue, 11 Jun 2024, Richard Sandiford wrote:
>
> > Don't think it makes any difference, but:
> >
> > Richard Biener writes:
> > > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo,
> > > stmt_vec_info stmt_info,
> > >
The following refactors the code to detect necessary peeling for
gaps, in particular the PR103116 case when there is no gap but
the group size is smaller than the vector size. The testcase in
PR114107 shows we fail to SLP
for (int i=0; i
The following makes peeling of a single scalar iteration handle more
gaps, including non-power-of-two cases. This can be done by rounding
up the remaining access to the next power-of-two which ensures that
the next scalar iteration will pick at least the number of excess
elements we access.
I've
This avoids falling back to elementwise accesses for strided SLP
loads when the group size is not a multiple of the vector element
size. Instead we can use a smaller vector or integer type for the load.
For stores we can do the same though restrictions on stores we handle
and the fact that store-
Hi Gaius,
>> static tree
>> build_m2_short_real_node (void)
>> {
>> - tree c;
>> -
>> - /* Define `REAL'. */
>> -
>> - c = make_node (REAL_TYPE);
>> - TYPE_PRECISION (c) = FLOAT_TYPE_SIZE;
>> - layout_type (c);
>> - return c;
>> + /* Define `SHORTREAL'. */
>> + layout_type (float_type
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653387.html
BR,
Kewen
on 2024/6/3 11:00, 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 mac
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653339.html
BR,
Kewen
on 2024/6/3 11:00, 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 mac
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653342.html
BR,
Kewen
on 2024/6/3 11:00, 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 mac
Richard Biener writes:
> On Wed, 12 Jun 2024, Richard Biener wrote:
>
>> On Tue, 11 Jun 2024, Richard Sandiford wrote:
>>
>> > Don't think it makes any difference, but:
>> >
>> > Richard Biener writes:
>> > > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo,
>> > > stmt_vec_in
LGTM!
Thanks!
在 2024/6/9 下午9:48, Xi Ruoyao 写道:
A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and
pair, and twice fast as a srli/slli pair. When the src reg and the dst
reg happens to be the same, the move instruction can be optimized away.
gcc/ChangeLog:
* conf
On Wed, Jun 12, 2024 at 5:12 AM Hongyu Wang wrote:
>
> Hi,
>
> For CTEST, we don't have conditional AND so there's no optimization
> opportunity to write a new ctest pattern. Emit ctest when ccmp did
> comparison to const 0 to save bytes.
>
> Bootstrapped & regtested under x86-64-pc-linux-gnu.
>
>
On Wed, Jun 12, 2024 at 12:00 PM Uros Bizjak wrote:
>
> On Wed, Jun 12, 2024 at 5:12 AM Hongyu Wang wrote:
> >
> > Hi,
> >
> > For CTEST, we don't have conditional AND so there's no optimization
> > opportunity to write a new ctest pattern. Emit ctest when ccmp did
> > comparison to const 0 to sa
Hey there,
I wanted to come back to maintaining the ia64 port as discussed
preciously the other month on the gcc list.
It has been some days as we were busy releasing the biggest release of
our Embdded T2/Linux distribution [0] and we obviously did not want to
propose to enable LRA for IA-64 in t
On 11/06/2024 17:35, Wilco Dijkstra wrote:
> Hi Christophe,
>
>> PR target/115153
> I guess this is typo (should be 115188) ?
>
> Correct.
>
>> +/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so I
>> think you don't need to add it
> here?
>
> Indeed, it's not s
On Wed, 12 Jun 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 12 Jun 2024, Richard Biener wrote:
> >
> >> On Tue, 11 Jun 2024, Richard Sandiford wrote:
> >>
> >> > Don't think it makes any difference, but:
> >> >
> >> > Richard Biener writes:
> >> > > @@ -2151,7 +2151,16 @
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to
support this for some years to come.
gcc/
* config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the
list of obsoleted targets.
contrib/
* config-list.mk (LIST): no --enable-obsolete for ia64*-*-
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e2870eef2ef..4328ca5f84c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ i386 port Jan Hubicka
i386 port Uros Bizjak
i386 vector ISA ext
gcc/
* config/ia64/ia64.cc: Enable LRA for ia64.
* config/ia64/ia64.md: Likewise.
* config/ia64/predicates.md: Likewise.
---
gcc/config/ia64/ia64.cc | 7 ++-
gcc/config/ia64/ia64.md | 4 ++--
gcc/config/ia64/predicates.md | 2 +-
3 files changed, 5 insertion
On 12/06/2024 11:35, Richard Earnshaw (lists) wrote:
> On 11/06/2024 17:35, Wilco Dijkstra wrote:
>> Hi Christophe,
>>
>>> PR target/115153
>> I guess this is typo (should be 115188) ?
>>
>> Correct.
>>
>>> +/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so
>>>
On Wed, 12 Jun 2024, Rene Rebe wrote:
>
> gcc/
> * config/ia64/ia64.cc: Enable LRA for ia64.
> * config/ia64/ia64.md: Likewise.
> * config/ia64/predicates.md: Likewise.
That looks simple enough. I cannot find any copyright assignment on
file with the FSF so you probably wa
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
have unknown prefixed ISA extension `zaamo' when building.
Pan
-Original Message-
From: Patrick O'Neill
Sent: Wednesday, June 12, 2024 1:08 AM
To: Jeff Law ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com;
On Jun 12 2024, Li, Pan2 wrote:
> Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
> have unknown prefixed ISA extension `zaamo' when building.
There needs to be a configure check if binutils can grok the extension.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG
The feature doesn't work on non-Linux hosts, at present, so skip the tests
entirely.
On Linux systems that have insufficient lockable memory configured we still
need to fail or else the feature won't be getting tested when we think it is,
but now there's a message to explain why.
libgomp/ChangeLo
This patch series is a rework of the v4 series I posted in May:
https://patchwork.sourceware.org/project/gcc/list/?series=34587&state=%2A&archive=both
This adds a new patch (1/6) that adjusts criticisms of the testcases
that were already committed. The same issues have been fixed in the new
testc
Add a new option. It's inactive until I add some follow-up patches.
gcc/ChangeLog:
* common.opt: Add -foffload-memory and its enum values.
* coretypes.h (enum offload_memory): New.
* doc/invoke.texi: Document -foffload-memory.
---
gcc/common.opt | 16 +++
Compared to the previous v4 (1/5) posting of this patch:
- The enumeration of the ompx allocators have been moved (again) to 200
(as 100 is already in use by another toolchain vendor and this seems
like a possible source of confusion).
- The "ompx" has also been changed to "ompx_gnu" to highlig
This patch was already approved, in the v3 posting by Tobias Burnus
(with one caveat about initialization location), but wasn't committed at
that time as I didn't want to disentangle it from the textual
dependencies on the other patches in the series.
--
Use Cuda to pin memory, instead of Lin
Implement the -foffload-memory=pinned option such that libgomp is
instructed to enable fully-pinned memory at start-up. The option is
intended to provide a performance boost to certain offload programs without
modifying the code.
This feature only works on Linux, at present, and simply calls mloc
This patch introduces a new custom memory allocator for use with pinned
memory (in the case where the Cuda allocator isn't available). In future,
this allocator will also be used for Unified Shared Memory. Both memories
are incompatible with the system malloc because allocated memory cannot
share
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 HImode:
> cnt v1.16b, v.16b
>
On 2024-06-11 16:00, Richard Earnshaw (lists) wrote:
On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.
gcc/testsuite/ChangeLog:
PR target/115253
* gcc.targe
On 2024-06-11 15:59, Richard Earnshaw (lists) wrote:
On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog pro
David: Ping.
Le 2024-04-26 à 09 h 51, Antoni Boucher a écrit :
Now that we have a more general way to check if target-dependent types
are supported (see this commit:
https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2
"Kewen.Lin" writes:
> Hi,
>
> Gentle ping:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653387.html
>
> BR,
> Kewen
>
> on 2024/6/3 11:00, Kewen Lin wrote:
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as
The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing the Load-Acquire RCpc Pair Ordered, and
Store-Release Pair Ordered operations in the form of LDIAPP and STILP.
These operations are single
From: Pan Li
After we support the scalar unsigned form 1 and 2, we would like
to introduce more forms include the branch and branchless. There
are forms 3-10 list as below:
Form 3:
#define SAT_SUB_U_3(T) \
T sat_sub_u_3_##T (T x, T y) \
{ \
return x > y ? x - y : 0; \
}
Form 4:
On Thu, 5 May 2022, Alexandre Oliva via Gcc-patches wrote:
> [PR100106] Reject unaligned subregs when strict alignment is required
>
> From: Alexandre Oliva
>
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of
Andrew Stubbs wrote:
The feature doesn't work on non-Linux hosts, at present, so skip the tests
entirely.
On Linux systems that have insufficient lockable memory configured we still
need to fail or else the feature won't be getting tested when we think it is,
but now there's a message to explain
Andrew Stubbs wrote:
Compared to the previous v4 (1/5) posting of this patch:
- The enumeration of the ompx allocators have been moved (again) to 200
(as 100 is already in use by another toolchain vendor and this seems
like a possible source of confusion).
- The "ompx" has also been changed
On Tue, Jun 11, 2024 at 11:46 AM Victor Do Nascimento
wrote:
>
> At present the autovectorizer fails to vectorize simple loops
> involving calls to `__builtin_prefetch'. A simple example of such
> loop is given below:
>
> void foo(double * restrict a, double * restrict b, int n){
> int i;
> f
Hi,
> On Jun 12, 2024, at 13:01, Richard Biener wrote:
>
> On Wed, 12 Jun 2024, Rene Rebe wrote:
>>
>> gcc/
>>* config/ia64/ia64.cc: Enable LRA for ia64.
>>* config/ia64/ia64.md: Likewise.
>>* config/ia64/predicates.md: Likewise.
>
> That looks simple enough. I cannot
On Wed, Jun 12, 2024 at 6:39 AM Andrew Pinski wrote:
>
> As mentioned by Jeff in r15-831-g05daf617ea22e1d818295ed2d037456937e23530, we
> don't handle
> `(X | Y) & ~Y` -> `X & ~Y` on the gimple level when there are some different
> signed
> (but same precision) types dealing with matching `~Y` wi
On Wed, 12 Jun 2024, René Rebe wrote:
> Hi,
>
> > On Jun 12, 2024, at 13:01, Richard Biener wrote:
> >
> > On Wed, 12 Jun 2024, Rene Rebe wrote:
> >>
> >> gcc/
> >>* config/ia64/ia64.cc: Enable LRA for ia64.
> >>* config/ia64/ia64.md: Likewise.
> >>* config/ia64/predica
On Mon, Jun 10, 2024 at 9:27 PM Philipp Tomsich
wrote:
>
> On Mon, 10 Jun 2024 at 20:03, Jeff Law wrote:
> >
> >
> >
> > On 6/10/24 1:55 AM, Manolis Tsamis wrote:
> >
> > >>
> > > There was an older submission of a load-pair specific pass but this is
> > > a complete reimplementation and indeed s
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 best be a leftover that wasn't
properly cleaned
Hello Richard:
On 12/06/24 3:02 am, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Richard:
>>
>> On 11/06/24 9:41 pm, Richard Sandiford wrote:
>>> Ajit Agarwal writes:
>> Thanks a lot. Can I know what should we be doing with neg (fma)
>> correctness failures with load fusion.
On Jun 12, 2024, at 15:00, Richard Biener wrote:
>
> On Wed, 12 Jun 2024, René Rebe wrote:
>
>> Hi,
>>
>>> On Jun 12, 2024, at 13:01, Richard Biener wrote:
>>>
>>> On Wed, 12 Jun 2024, Rene Rebe wrote:
gcc/
* config/ia64/ia64.cc: Enable LRA for ia64.
* config
On 12/06/2024 09:53, Andre Vieira (lists) wrote:
>
>
> On 06/06/2024 12:53, Richard Earnshaw (lists) wrote:
>> On 05/06/2024 17:07, Andre Vieira (lists) wrote:
>>> Hi,
>>>
>>> This patch adds missing assembly directives to the CMSE library wrapper to
>>> call functions with attribute cmse_nonsec
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1210-g1cae1a5ce088c1.
gcc/cp/ChangeLog:
* error.cc (append_formatted_chunk): Move part of body into
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1209-gc5e3be456888aa.
gcc/analyzer/ChangeLog:
* access-diagram.cc (access_range::dump): Update for fiel
Hello Richard:
On 12/06/24 3:02 am, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Richard:
>>
>> On 11/06/24 9:41 pm, Richard Sandiford wrote:
>>> Ajit Agarwal writes:
>> Thanks a lot. Can I know what should we be doing with neg (fma)
>> correctness failures with load fusion.
No semantics changes.
gcc/cp/ChangeLog:
* cp-tree.h (extract): Add new overload to return tree.
* parser.cc (cp_parser_asm_string_expression): Use tree extract.
* semantics.cc (cexpr_str::extract): Add new overload to return
tree.
---
gcc/cp/cp-tree.h| 1 +
Hi all,
On 12.06.24 15:19, René Rebe wrote:
On Jun 12, 2024, at 15:00, Richard Biener wrote:
On Wed, 12 Jun 2024, René Rebe wrote:
On Jun 12, 2024, at 13:01, Richard Biener wrote:
On Wed, 12 Jun 2024, Rene Rebe wrote:
not sure how you exactly did this though? I've never tried
testing of a
Dear Richard,
On 12.06.24 13:01, Richard Biener wrote:
[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without? Both from May:
https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.h
On 6/11/24 23:53, Andi Kleen wrote:
Sorry I must have misunderstood you. I thought the patch was already
approved earlier and I did commit. I can revert or do additional
changes.
I only meant to approve the refactoring patch, but no worries.
On Tue, Jun 11, 2024 at 04:31:30PM -0400, Jason Me
On 6/12/24 12:47 AM, Richard Biener wrote:
One of the points I wanted to make is that sched1 can make quite a
difference as to the relative distance of the store and load and
we have the instruction window the pass considers when scanning
(possibly driven by target uarch details). So doing
On Mon, 3 Jun 2024, David Malcolm wrote:
> > Thank you for fixing this up. Is this a new requirement now for
> > .opt
> > file changes?
>
> Yes, as of GCC 14.
>
> I posted the objectives here:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636060.html
Thank you for the pointer.
On 6/12/24 10:02, Andi Kleen wrote:
No semantics changes.
gcc/cp/ChangeLog:
* cp-tree.h (extract): Add new overload to return tree.
* parser.cc (cp_parser_asm_string_expression): Use tree extract.
* semantics.cc (cexpr_str::extract): Add new overload to return
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Using memset is incorrect if the __bucket_ptr type is non-trivial, or
does not use an all-zero bit pattern for its null value.
Replace the three uses of memset with std::fill_n to set the pointers to
nullptr.
libstdc++-v3/ChangeLog:
* incl
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The shift operations for dynamic_bitset fail to zero out words where the
non-zero bits were shifted to a completely different word.
For a right shift we don't need to sanitize the unused bits in the high
word, because we know they were already clear
Richard Biener writes:
> On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote:
>>
>> Hi,
>>The cost return from set_src_cost might be zero. Zero for
>> pattern_cost means unknown cost. So the regularization converts the zero
>> to COSTS_N_INSNS (1).
>>
>>// pattern_cost
>>cost = set_src
Hi Faust.
Thanks for the patch.
Please see a question below.
> This patch enables -gprune-btf by default in the BPF backend when
> generating BTF information, and fixes BPF CO-RE generation when using
> -gprune-btf.
>
> When generating BPF CO-RE information, we must ensure that types used
> in C
On 6/12/24 04:21, Andreas Schwab wrote:
On Jun 12 2024, Li, Pan2 wrote:
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
have unknown prefixed ISA extension `zaamo' when building.
There needs to be a configure check if binutils can grok the extension.
Ack. I'l
On Wed, 12 Jun 2024 10:09:06 PDT (-0700), Patrick O'Neill wrote:
On 6/12/24 04:21, Andreas Schwab wrote:
On Jun 12 2024, Li, Pan2 wrote:
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
have unknown prefixed ISA extension `zaamo' when building.
There needs to be
asm constexpr now only accepts the same string types as C++26 assert,
e.g. string_view and string. Adjust test suite and documentation.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Remove support
for const char * for asm constexpr.
gcc/ChangeLog:
*
To get better error recovery.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Parse close
parent when constexpr extraction fails.
---
gcc/cp/parser.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 98
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Use correct error
message.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-asm-3.C: Adjust for new message.
---
gcc/cp/parser.cc | 2 +-
gcc/testsuite/g++.dg/cpp1z/constexpr-as
On 6/12/24 09:55, Jose E. Marchesi wrote:
>
> Hi Faust.
> Thanks for the patch.
> Please see a question below.
>
>> This patch enables -gprune-btf by default in the BPF backend when
>> generating BTF information, and fixes BPF CO-RE generation when using
>> -gprune-btf.
>>
>> When generating B
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
-- >8 --
Here during overload resolution we have two strictly viable ambiguous
candidates #1 and #2, and two non-strictly viable candidates #3 and #4
which we hold on to ever since r14-6522. These latter candidate
On Wed, 12 Jun 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk/14?
>
> -- >8 --
>
> Here during overload resolution we have two strictly viable ambiguous
> candidates #1 and #2, and two non-strictly viable candidates #3 and #4
> which
On 6/11/24 8:53 AM, pan2...@intel.com wrote:
From: Pan Li
The test cases of pr115387 are target independent, at least x86
and riscv are able to reproduce. Thus, move these cases to
the gcc.dg/torture.
The below test suites are passed.
1. The rv64gcv fully regression test.
2. The x86 full
On 6/11/24 12:03 PM, Patrick O'Neill wrote:
This series moves the atomic-related riscv testcases into their own folder and
fixes some minor bugs/rigidity of existing testcases.
This series is OK.
jeff
On 6/11/24 12:21 PM, Patrick O'Neill wrote:
I made the whitespace cleanup patch (trailing whitespace, leading groups
of 8 spaces -> tabs) for
target-supports.exp and got a diff of 584 lines.
Is this still worth doing or will it be too disruptive for rebasing/
other people's development?
An update on this task. (Also need more suggestions -:)
I have an initial implemenation locally, with this gcc, I can get the following
message with the testing case in PR109071:
[ 109071]$ cat t.c
extern void warn(void);
static inline void assign(int val, int *regs, int *index)
{
if (*index >
On 6/12/24 11:12, Jeff Law wrote:
On 6/11/24 12:03 PM, Patrick O'Neill wrote:
This series moves the atomic-related riscv testcases into their own
folder and
fixes some minor bugs/rigidity of existing testcases.
This series is OK.
jeff
Committed, thanks.
Patrick
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
Since the terms of a requires-clause are grammatically primary-expressions
rather than e.g. postfix-expressions, it seems we need to explicitly
handle and diagnose the case where a term parses to bare unre
I missed this target-specific usage of pretty_printer::buffer when
making the fields private in r15-1209-gc5e3be456888aa; sorry.
Verified that this fixes the build breakage with
--target=aarch64-unknown-linux-gnu.
Pushed as r15-1220-ge35f4eab68773b.
gcc/ChangeLog:
PR bootstrap/115465
On 12/06/24 12:42 +0200, Rene Rebe wrote:
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to
support this for some years to come.
gcc/
* config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the
list of obsoleted targets.
contrib/
* config-list.mk
On 12/06/24 12:33 +0200, Rene Rebe wrote:
Hey there,
I wanted to come back to maintaining the ia64 port as discussed
preciously the other month on the gcc list.
It has been some days as we were busy releasing the biggest release of
our Embdded T2/Linux distribution [0] and we obviously did not
> On 6/12/24 09:55, Jose E. Marchesi wrote:
>>
>> Hi Faust.
>> Thanks for the patch.
>> Please see a question below.
>>
>>> This patch enables -gprune-btf by default in the BPF backend when
>>> generating BTF information, and fixes BPF CO-RE generation when using
>>> -gprune-btf.
>>>
>>> When g
This patch removes trailing whitespace and replaces leading groups of 8-16
spaces with tabs.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Cleanup whitespace.
Signed-off-by: Patrick O'Neill
---
Pre-approved here:
https://inbox.sourceware.org/gcc-patches/3312c6a8-8f34-43f0-8562-99
On 12/06/24 19:40 +0100, Jonathan Wakely wrote:
On 12/06/24 12:42 +0200, Rene Rebe wrote:
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to
support this for some years to come.
gcc/
* config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the
"exlicitly"
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
It seems we don't maintain visibility flags for concepts either, so
min_vis_expr_r should ignore them for now, otherwise after r14-6789 we
incorrectly give function templates that use a concept-id in their
si
On 12/06/24 16:09 +0200, Frank Scheiner wrote:
Dear Richard,
On 12.06.24 13:01, Richard Biener wrote:
[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without? Both from May:
https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware
On Wed, Jun 12, 2024 at 02:23:18PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> > +# Return 1 if this is a PowerPC target supporting -mcpu=power11.
> > +
> > +proc check_effective_target_power11_ok { } {
> > +if { ([istarget powerpc*-*-*]) } {
> > + return [check_no_compiler_messages power11_ok ob
1 - 100 of 149 matches
Mail list logo