On Fri, 20 Sep 2024, Tobias Burnus wrote:
> This is supposed to document that GCC now supports offloading,
> e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper)
> or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265
> and https://gcc.gnu.org/PR111937 for the associated PRs.
>
> I thin
Hi all,
pushed as gcc-15-6292-g9684e70952a. Thanks for the review.
- Andre
On Mon, 16 Dec 2024 19:15:12 +0100
Harald Anlauf wrote:
> Hi Andre,
>
> Am 16.12.24 um 15:26 schrieb Andre Vehreschild:
> > Hi Harald,
> >
> > thanks for finding the bug so quickly. I took another look and came up with
On Tue, 2024-12-17 at 12:52 +0800, Lulu Cheng wrote:
>
> 在 2024/12/17 下午12:30, Xi Ruoyao 写道:
> > On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
> > > 在 2024/12/16 下午9:20, Xi Ruoyao 写道:
> > > /* snip */
> > > > +;; For HImode it's a little complicated...
> > > > +(define_expand "rbithi"
> > >
Hi Akram,
> On 14 Nov 2024, at 16:53, Akram Ahmad wrote:
>
> This renames the existing {s,u}q{add,sub} instructions to use the
> standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
> IFN_SAT_SUB.
>
> The NEON intrinsics for saturating arithmetic and their corresponding
> builtins
Hi,
in PR117682 we build an interleaving pattern
{ 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
33, 233, 241, 57, 193, 137, 145, 217, 97, 41,
49, 121 };
with negative step expecting wraparound semantics due to -fwrapv.
For building inte
On 12/13/24 6:05 PM, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970
This fixes one place in module.cc that I missed updating for 64-bit
location_t in r15-5616. bootstrap + regtested on x86-64 + aarch64. Also
verified that the regression reported on the PR is fixed
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since atomic constraints are interned the subsumption machinery can
safely use pointer instead of structural hashing for them. This speeds
up compilation of the testcase in the PR from ~3s to ~2s.
P
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk? Shall we also backport this to release branches?
It's not a regression but seems like a safe fix for an inconvenient
issue.
-- >8 --
For the testcase in the PR we hang during constraint normalization
ultimately becau
On 12/16/24 6:48 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destru
On Tue, Dec 17, 2024 at 10:25:48AM +0100, Matthias Klose wrote:
> On 17.12.24 00:58, Joseph Myers wrote:
> > On Mon, 16 Dec 2024, Matthias Klose wrote:
> >
> > > On 14.12.24 15:38, Matthias Klose wrote:
> > > > I tried to use the patches to build binary packages for Debian. Found
> > > > some
> >
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Test fails for Cortex-M0 with:
>
> .../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void
> ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...'
>
> According to
Alexandre Oliva writes:
> When ifcombine_mark_ssa_name is called directly, rather than by
> ifcombine_mark_ssa_name_walk, we need to check that name is an
> SSA_NAME at the caller or in the function itself. For convenience and
> safety, I'm moving the checks from _walk to the implementation prop
Ping.
On 12/2/24 11:49, Jørgen Kvalsvik wrote:
Ping.
On 11/21/24 20:14, Jørgen Kvalsvik wrote:
Ping.
On 11/12/24 09:56, Jørgen Kvalsvik wrote:
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Hi All,
This bug was so obviously in defiance of the standard that I pushed it to
mainline as r15-6260. I meant to post this message immediately but was
distracted before I could press send. I will be backporting today.
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/trans-ex
On 17/12/2024 08:01, Gerald Pfeifer wrote:
> On Fri, 20 Sep 2024, Tobias Burnus wrote:
>> This is supposed to document that GCC now supports offloading,
>> e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper)
>> or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265
>> and https://gcc.gnu
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
> https://linaro.atlassian.net/browse/GNU-1463.
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp: Added corresponding -mtune= option
>
Hi,
On Tue, Dec 03 2024, Richard Biener wrote:
> On Tue, Dec 3, 2024 at 12:09 PM Martin Jambor wrote:
>> On Fri, Nov 15 2024, Richard Biener wrote:
>> > On Fri, Nov 15, 2024 at 1:45 PM Jan Hubicka wrote:
>> >> >
>> >> > The patch only ever skips just one conversion, never a chain of them and
>>
On 12/16/24 10:28 AM, Palmer Dabbelt wrote:
On Mon, 16 Dec 2024 08:37:13 PST (-0800), c...@cyyself.name wrote:
There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace
On 2024-12-17 15:41, Richard Earnshaw (lists) wrote:
On 17/12/2024 14:32, Torbjorn SVENSSON wrote:
On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https:/
On 17/12/2024 14:32, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
>> On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
>>> Ok for trunk?
>>>
>>> --
>>>
>>> Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
>>> https://linaro.atlassian.net/browse/
On 2024-12-17 14:33, Richard Earnshaw (lists) wrote:
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test fails for Cortex-M0 with:
.../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void
ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...)
On 12/16/24 8:31 AM, Oliver Kozul wrote:
The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2
Hi,
On Tue, Nov 05 2024, Jan Hubicka wrote:
>> Hi,
>>
>> I believe that the current function ipa_range_set_and_normalize lacks
>> a check that a base of an ADDR_EXPR lacks a test whether the base
>> really cannot be NULL, so this patch adds it. Moreover, I never liked
>> the name as I do not thi
> > --- a/gcc/config/riscv/riscv-vector-builtins.cc
> > +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> > @@ -4089,7 +4089,23 @@ function_expander::add_input_operand (unsigned argno)
> > {
> > tree arg = CALL_EXPR_ARG (exp, argno);
> > rtx x = expand_normal (arg);
> > - add_input_opera
On Sun, Dec 15, 2024 at 1:31 AM Jeff Law wrote:
>
>
>
> On 12/9/24 1:56 AM, Kito Cheng wrote:
> > This patch set implements the proposal from riscv-c-api-doc[1].
> > It adds two constraints and one modifier with the goal of improving the user
> > experience for `.insn`, making it easier for users
On 12/15/24 3:47 PM, Anton Blanchard wrote:
gcc/ChangeLog
* doc/invoke.texi (RISC-V): Add thead-c906, xiangshan-nanhu to
-mcpu, add generic-ooo and remove thead-c906 from -mtune.
Signed-off-by: Anton Blanchard
Thanks. I've pushed this to the trunk.
jeff
On 12/15/24 3:47 PM, Anton Blanchard wrote:
This adds the Tenstorrent Ascalon 8 wide architecture (tt-ascalon-d8)
to the list of known cores.
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add tt-ascalon-d8.
* config/riscv/riscv.cc (tt_ascalon_d8_tune_info): New.
* do
On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Ad
On 17.12.24 00:58, Joseph Myers wrote:
On Mon, 16 Dec 2024, Matthias Klose wrote:
On 14.12.24 15:38, Matthias Klose wrote:
I tried to use the patches to build binary packages for Debian. Found some
issues:
tried to build libgcobol on more architectures, please find the attached patch
to disa
The generic expand_vector_piecewise routine supports lowering of
a vector operation to vector operations of smaller size. When
computing the extract position from the larger vector it uses the
element size in bits of the original result vector to determine
the number of elements in the smaller vec
Hi all, hello PA,
Tobias Burnus wrote:
Paul-Antoine Arras wrote:
See the revised patch attached and my comments below.
I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
Additional comments: Can you hoist the condition
ACATS-4 ca11d02 exposed an error in the logic for recognizing and
identifying the inner object in decode_field_ref: a view-converting
load, inserted in a previous successful field merging operation, was
recognized by gimple_convert_def_p within decode_field_reference, and
as a result we took its
The testcase shows that conversions that would impact negatively the
ifcombine field merging implementation won't always have been
optimized out by the time we reach ifcombine.
There's probably room to support multiple conversions with extra
logic, but this workaround should avoid codegen errors
There was a thinko in the testcase field-merge-9.c: I overcorrected it
for big-endian.
As a bonus, I'm including stdbool.h in field-merge-12.c, because I
used bool without the header there.
Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
other ifcombine patches. Barring ob
When ifcombine_mark_ssa_name is called directly, rather than by
ifcombine_mark_ssa_name_walk, we need to check that name is an
SSA_NAME at the caller or in the function itself. For convenience and
safety, I'm moving the checks from _walk to the implementation proper.
Regstrapped on x86_64-linux
On Fri, Nov 15 2024, Martin Jambor wrote:
> Hi,
>
> On Thu, Nov 07 2024, Aldy Hernandez wrote:
>> Jan Hubicka writes:
>>
> 2024-11-01 Martin Jambor
>
> * ipa-prop.cc (ipa_compute_jump_functions_for_edge): When
> creating
> value-range jump functions fro
On 15/11/2024 10:15, Christophe Lyon wrote:
> On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
> wrote:
>>
>>
>>
>> On 2024-11-14 16:53, Christophe Lyon wrote:
>>> On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
>>> wrote:
Ok for trunk and releases/gcc-14?
--
When the
From: kelefth
During the initialization of the base register for the zero-offset store, in
the case that we are eliminating the load, we used a paradoxical subreg
assuming that we don't care about the higher bits of the register. This led to
writing wrong values when we were not updating the whol
This pass is used to optimise assignments to the FPMR register in
aarch64. I chose to implement this as a middle-end pass because it
mostly reuses the existing RTL PRE code within gcse.cc.
Compared to RTL PRE, the key difference in this new pass is that we
insert new writes directly to the destin
If s-trasym.adb (System.Traceback.Symbolic, used as a renaming by
GNAT.Traceback.Symbolic) is given a traceback from a
position-independent executable, it does not include the executable's
load address in the report. This is necessary in order to decode the
traceback report.
This version of the pa
Pinging
On 27/11/2024 20:27, Akram Ahmad wrote:
Hi all,
This patch series adds support for 2 new cases of unsigned scalar saturating
arithmetic
(one addition, one subtraction). This results in more valid patterns being
recognised,
which results in a call to .SAT_ADD or .SAT_SUB where relevant
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668794.html
On 14/11/2024 15:53, Akram Ahmad wrote:
Hi all,
This patch series introduces standard names for scalar, Adv. SIMD, and
SVE saturating arithmetic instructions in the aarch64 backend.
Additional tests are added for scal
> Looking at the log for the reload pass, it is found that "Changing pseudo 209
> in operand 3 of insn 69 on equiv 0x 1". It converts the vl operand in insn
> from the expected register(reg:DI 209) to the constant 1(const_int 1 [0x1]).
>
> This conversion occurs because, although the predicate for
On Mon, 2024-12-16 at 11:32 -0500, James K. Lowden wrote:
> On Mon, 16 Dec 2024 23:48:52 + (UTC)
> Joseph Myers wrote:
>
> > However, if introducing a Bison dependency, it needs to be
> > documented
> > (being specific about version requirements) in install.texi.
>
> Under "Tools/packages n
Hi Jason,
Thanks for the quick feedback!
On 2024-12-16 17:11, Jason Merrill wrote:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-o
We don't know what state an arbitrary sequence container will be in
after moving from it, so a moved-from std::priority_queue needs to clear
the moved-from container to ensure it doesn't contain elements that are
in an invalid order for the queue. An alternative would be to call
std::make_heap agai
On Tue, 17 Dec 2024 at 19:38, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 22:39, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
> > >
> > > The template `future.wait_until` will expand to
> > > `_M_load_and_test_until_impl` where it will call
> > > `_M_loa
On 9/11/24 8:26 AM, Jakub Jelinek wrote:
On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
In the header_module_p case, it is valid to have internal linkage
definitions (e.g. in an anonymous namespace), but in that case the
{static,tls}_aggregates lists should still be in place to
On 9/5/24 3:20 AM, Jakub Jelinek wrote:
Hi!
Similarly for likely/unlikely attributes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-likely1.C: New test.
* g++.dg/cpp0x/attr-unli
On 9/5/24 3:27 AM, Jakub Jelinek wrote:
Hi!
When adding test coverage for maybe_unused attribute, I've run into
several things:
1) similarly to deprecated attribute, the attribute shouldn't pedantically
appertain to types other than class/enumeration definitions
2) similarly to deprecated at
This came up on IRC this morning and we talked a bit on the patchwork
call this morning. I'm not really sure what the right answer is here,
but it seems at least reasonable to talk about -- we've got a lot more
testing these days are we've been somewhat reasonable about following
the release stage
On 8/30/24 1:34 PM, Jakub Jelinek wrote:
On Mon, Aug 19, 2024 at 05:05:51PM -0400, Jason Merrill wrote:
I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
auto e = new int [n] [[deprecated
> From: Gerald Pfeifer
> Sent: Tuesday, December 17, 2024 3:57 PM
>
> On Mon, 25 Nov 2024, Jiang, Haochen wrote:
> > I will do all of the changes with little tweak here. The "and" should
> > be added (actually changed the previous "or" to "and") between
> > -mtune=knl and -mtune=knm.
>
> Thank y
24
# of expected failures 274
# of unsupported tests 87
/usr/home/kargl/gcc/obj/gcc/gfortran version 15.0.0 20241217
(experimental) (GCC)
The unexpected failures are all ASAN or LTO related. Jerryd has
indicated that the patch bootstraps on x86_64_linux_gnu and also
Hi all!
I would like to ping the patch in
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670763.html
(Message-Id: <20241204045717.12982-1-garth...@linux.alibaba.com>).
It is supposed to be a generalization of the existing stack pointer VALUE reuse
mechanism, based on Jakub's commit 2c0fa
On 9/5/24 3:15 AM, Jakub Jelinek wrote:
Hi!
This is a continuation of the series for the ignorability of standard
attributes, on top of
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermai
On 9/6/24 2:37 PM, Jakub Jelinek wrote:
Hi!
The following patch on top of the PR110345 P2552R3 series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.
On 8/30/24 1:31 PM, Jakub Jelinek wrote:
Hi!
The following testcase shows another issue where we just ignored
attributes without telling user we did that.
If there are any declarators, the ignoring of the attribute
are diagnosed in grokdeclarator etc., but if there is none
(and we don't error s
We have several overloads of std::deque::_M_insert_aux, one of which is
variadic and called by std::deque::emplace. With a suitable set of
arguments to emplace, it's possible for one of the non-variadic
_M_insert_aux overloads to be selected by overload resolution, making
emplace ill-formed.
Renam
The mapping from char to wchar_t needs to handle 'i' and 'I' but those
were absent from the table that is used for some non-ASCII encodings.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__to_wstring_numeric): Add 'i'
and 'I' to mapping.
---
Tested x86_64-linux.
libstd
Some bitfield compares with zero are optimized to range tests, so
instead of X & ~(Bit - 1) != 0 what reaches ifcombine is X > (Bit - 1),
where Bit is a power of two and X is unsigned.
This patch recognizes this optimized form of masked compares, and
attempts to merge them like masked compares,
On Dec 17, 2024, Sam James wrote:
>> +/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-vrp" */
> Missing closing '}'.
Thanks, I've fixed that, and retested.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Eng
On 12/17/24 14:21, Tobias Burnus wrote:
Hi Sandra,
thanks for the patch! One minor nit:
Sandra Loosemore wrote:
+To enable the processing of OpenACC directives @samp{#pragma omp}
#pragma acc – not #pragma omp.
Sigh, I need to get new glasses! Fixed with the attached patch.
-SandraFrom b3
On 9/5/24 3:17 AM, Jakub Jelinek wrote:
Hi!
This patch adds additional test coverage for the carries_dependency
attribute (unlike other attributes, the attribute actually isn't implemented
for real, so we warn even in the cases of valid uses because we ignore those
as well).
Bootstrapped/regtes
On 9/5/24 3:19 AM, Jakub Jelinek wrote:
Hi!
Similarly for fallthrough attribute. Had to add a second testcase because
the diagnostics for fallthrough not used within switch at all is done during
expansion and expansion won't happen if there are other errors in the
testcase.
Bootstrapped/regtes
On 8/30/24 1:29 PM, Jakub Jelinek wrote:
Hi!
As the following testcase shows, cp_parser_decl_specifier_seq
was calling warn_misplaced_attr_for_class_type only for class types
and not for enum types, while check_tag_decl calls them for both
class and enum types.
Enum types are really the same cas
On 11/22/24 11:00 AM, Marek Polacek wrote:
On Thu, Sep 19, 2024 at 10:36:01PM +0200, Jakub Jelinek wrote:
Hi!
The following patch uses type_id_in_expr_sentinel in a few spots which
did it all manually.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Nice cleanup. Patch
When a loaded field is sign extended, masked and compared, we used to
drop from the mask the bits past the original field width, which is
not correct.
Take note of the fact that the mask covered copies of the sign bit,
before clipping it, and arrange to test the sign bit if we're
comparing with ze
On Mon, Dec 16, 2024 at 04:53:42AM -0800, Damian Rouson wrote:
> including automatic GPU offloading. Then a few months ago, the death blow
> that I couldn’t work around was robust support for kind type parameters.
>
gfortran doesn't have robust kind type parameters?
% cat xx.f90
program foo
On Tue, Dec 17, 2024 at 10:36:09AM -0500, Jason Merrill wrote:
> On 12/16/24 6:48 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
> >
> > -- >8 --
> > This crash started with my r12-7803 but I believe the problem lies
> > elsewhere.
> >
> > build
> On Fri, 13 Dec 2024 at 17:13, Tamar Christina wrote:
> >
> > Hi All,
> >
> > We are currently generating a loop which has more comparisons than you'd
> > typically need as the probablities on the small size loop are such that it
> > assumes the likely case is that an element is not found.
> >
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14/13?
-- >8 --
Here during partial substitution of the requires-expression (as part of
CTAD constraint rewriting) we segfault from the INDIRECT_REF case of
convert_to_void due *f(u) being type-dependent. We should ju
On Mon, 16 Dec 2024 23:48:52 + (UTC)
Joseph Myers wrote:
> However, if introducing a Bison dependency, it needs to be documented
> (being specific about version requirements) in install.texi.
Under "Tools/packages necessary for building GCC", in Prequisites,
yes?
In gcc/cobol/parse,y, we
libstdc++-v3/ChangeLog:
* include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
Add parentheses to avoid -Wparentheses warning.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/debug/safe_local_iterator.h | 2 +-
1 file changed, 1 insertion(+), 1 de
On Wed, 31 Jul 2024 at 22:39, Jonathan Wakely wrote:
>
> On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
> >
> > The template `future.wait_until` will expand to
> > `_M_load_and_test_until_impl` where it will call
> > `_M_load_and_test_until*` with given time_point casted into second and
> > na
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR points out that we're not pretty-printing NONTYPE_ARGUMENT_PACK
so the compiler emits the ugly:
'nontype_argument_pack' not supported by dump_expr>
Fixed thus. I've wrapped the elements of the pack in { } because th
On 12/17/24 2:43 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This PR points out that we're not pretty-printing NONTYPE_ARGUMENT_PACK
so the compiler emits the ugly:
'nontype_argument_pack' not supported by dump_expr>
Fixed thus. I'v
On 12/17/24 1:44 PM, Torbjorn SVENSSON wrote:
Hi Jason,
Thanks for the quick feedback!
On 2024-12-16 17:11, Jason Merrill wrote:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-e
On 05/11/2024 07:55, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 15:41, Richard Earnshaw wrote:
>> On 01/11/2024 18:40, Richard Earnshaw (lists) wrote:
>>> On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execu
A further diagnostic remark:
* When moving to the GCC diagnostic functions, please prefer the versions
that take an explicit location (which should be based on the locations of
the relevant source tokens in the COBOL source - preferably an accurate
range for exactly which tokens are relevant fo
On 12/17/24 5:05 AM, Jin Ma wrote:
I missed some information because of the long time.
Happens to me all the time ;-)
As I said before, instead of using UNSPEC, In the curr_insn_transform function,
the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]
On 8/3/24 2:36 PM, Jakub Jelinek wrote:
Hi!
The following patch (again, on top of the #embed patchset, so
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657049.htm
On 11/22/24 4:31 AM, Jakub Jelinek wrote:
On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
On Wed, 6 Nov 2024, Jakub Jelinek wrote:
+ error_at (loc, "%<:%> constraint operand is not address "
+"of a function or non-automatic variable
On 11/22/24 4:07 AM, Jakub Jelinek wrote:
On Fri, Nov 22, 2024 at 12:01:21AM +, Joseph Myers wrote:
On Mon, 18 Nov 2024, Jakub Jelinek wrote:
+@smallexample
+extern void foo (void), bar (void);
+int v;
+extern int w;
+asm (".globl %cc0, %cc2; .text; %cc0: call %cc1; ret; .data; %cc2: .word
> +/* { dg-require-effective-target riscv_v } */
> +/* { dg-require-effective-target rvv_zvl256b_ok } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -fwrapv" }
> */
Ah, I forgot _zvl256b in the -march string. It seems to still fail with the
settings as posted but I'll st
On 12/17/24 12:08 PM, Marek Polacek wrote:
On Tue, Dec 17, 2024 at 10:36:09AM -0500, Jason Merrill wrote:
On 12/16/24 6:48 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
> Am 16.12.2024 um 09:10 schrieb Jennifer Schmitz :
>
>
>
>> On 14 Dec 2024, at 09:32, Richard Biener wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
Am 13.12.2024 um 18:00 schrieb Jennifer Schmitz :
>>>
>>>
>>>
On 13 Dec 2024, at 13:40, Richard
On Mon, 16 Dec 2024, James K. Lowden wrote:
> On Mon, 16 Dec 2024 23:48:52 + (UTC)
> Joseph Myers wrote:
>
> > However, if introducing a Bison dependency, it needs to be documented
> > (being specific about version requirements) in install.texi.
>
> Under "Tools/packages necessary for buil
On Fri, 13 Dec 2024, David Malcolm wrote:
> For the rest of GCC we use either texinfo (.texi files) or sphinx
> (.rst) files; the manpages and HTML are both generated from the same
> sources. I don't if using these formats is a hard requirement. If so
> one converter I know of that can supposedl
On 2024-12-17 15:38, Torbjorn SVENSSON wrote:
On 2024-12-17 14:33, Richard Earnshaw (lists) wrote:
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test fails for Cortex-M0 with:
.../pr81812.C:6:8: error: generic thunk code fails for method
'virtual vo
PR c/26154 is one of our oldest documentation issues. The only
discussion of OpenMP support in the GCC manual is buried in the "C
Dialect Options" section, with nothing at all under "Extensions". The
Fortran manual does have separate sections for OpenMP and OpenACC
extensions so I have copy-edite
On 12/12/24 1:42 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This ICE started with the recent prvalue optimization (r15-6052). In
cp_fold_r we have:
if (tree &init = TARGET_EXPR_INITIAL (stmt))
{
cp_walk_tree (&init,
Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g. std::copy(first, last, first) which
violates the p
> > +}
> > + cgraph_simd_clone *sc = node->simdclone;
> > +
> > + for (unsigned i = 0; i < sc->nargs; ++i)
> > +{
> > + bool is_mask = false;
> > + tree type;
> > + switch (sc->args[i].arg_type)
> > + {
> > + case SIMD_CLONE_ARG_TYPE_MASK:
> > + is_mask = true;
> >
On Tue, Dec 17, 2024 at 10:43:49AM -0500, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk? Shall we also backport this to release branches?
> It's not a regression but seems like a safe fix for an inconvenient
> issue.
>
> -- >8 --
>
> For
On Tue, 17 Dec 2024, Marek Polacek wrote:
> On Tue, Dec 17, 2024 at 10:43:49AM -0500, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk? Shall we also backport this to release branches?
> > It's not a regression but seems like a safe fix f
On 11/27/24 3:53 AM, Nathaniel Shead wrote:
Gentle ping for this series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665108.html
Most of the patches no longer applied cleanly to trunk since the last
time I pinged this so I'm attaching newly rebased patches.
One slight adjustment I've
Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85).
Ok for trunk?
--
Without the escape of the tab, newline and semicolon, the generated
assembler output will not match the expected assmbler in the test cases.
Fixes Linaro CI reported regression on r15-6166-gb7e11b499922 in
https://linaro.
Thanks Paul.
Regards, Jerry
On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> This bug was so obviously in defiance of the standard that I pushed it to
> mainline as r15-6260. I meant to post this message immediately but was
> distracted bef
> Am 18.12.2024 um 05:00 schrieb Alexandre Oliva :
>
> When a loaded field is sign extended, masked and compared, we used to
> drop from the mask the bits past the original field width, which is
> not correct.
>
> Take note of the fact that the mask covered copies of the sign bit,
> before cl
1 - 100 of 105 matches
Mail list logo
