Hi!
In r15-4286 I've introduced a typo, part of the change was
- cpp_error (pfile, CPP_DL_ERROR, "'\\o' not followed by '{'");
+ cpp_error (pfile, CPP_DL_ERROR, "%<\\o%> not followed by %<}%>");
which turned { into }. This patch fixes it back.
Bootstrapped/regtested on x86_64-linux a
On 2025-03-11 16:13, Richard Earnshaw wrote:
On 11/03/2025 13:46, Torbjorn SVENSSON wrote:
Is it okay to backport below patch and r15-7890-gb7f5d911480 to
releases/gcc-14?
Yes, sure.
Pushed as r14.2.0-877-gf1dd3a17cf3 and r14.2.0-878-gde08b13018a.
Kind regards,
Torbjörn
R.
Kind reg
Robert Dubner writes:
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: Tuesday, March 11, 2025 17:40
>> To: Robert Dubner
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Add Robert Dubner to Maintainers
>>
>> On Tue, Mar 11, 2025 at 02:24:26PM -0500, Robert Dubner wrote:
>>
On 3/10/25 6:31 PM, Marek Polacek wrote:
build_over_call has:
t = build2 (MODIFY_EXPR, void_type_node,
build2 (MEM_REF, array_type, arg0, alias_set),
build2 (MEM_REF, array_type, arg, alias_set));
val = build2 (COMPOUND_EXPR, TREE_T
Robert Dubner writes:
>
> I need to be able to change, at the very least, the Assignment field. I
> don't seem to have any way of doing that.
Make sure your email address on Bugzilla is x...@gcc.gnu.org. Using that
address grants the account editbugs privileges.
sam
Earlier in this discussion of a testsuite, the question came up about
generating an error return in COBOL source code.
In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;". When
executed in the initial "top-level" program-id, it results in the value 1
being passed back to the _start
On 3/4/25 4:02 AM, Jakub Jelinek wrote:
Hi!
The following testcases (one with #embed, one with large initializer
turned into RAW_DATA_CST) show that I forgot to handle RAW_DATA_CST in
module streaming.
Similar to the PCH case we need to stream out RAW_DATA_CST with NULL
RAW_DATA_OWNER (i.e. a t
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 11, 2025 17:40
> To: Robert Dubner
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Add Robert Dubner to Maintainers
>
> On Tue, Mar 11, 2025 at 02:24:26PM -0500, Robert Dubner wrote:
> > As described in https://gcc.gnu
On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> I think the patch as-is is more robust, but still - ugh ... I wonder
> whether we can instead avoid introducing the COMPLEX_EXPR at all
> at -O0?
Can we set DECL_NOT_GIMPLE_REG_P at -O0 during gimplification (where
we've already han
PING!
On Thu, 20 Feb 2025 10:54:30 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch makes an attempt to announce the ABI-changes in the coarrays
> library. Me being German always has difficulties to find a proper wording. So
> please propose improvements.
>
> Stupid question: How to I
Hi Jason,
On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote:
> On 3/5/25 10:39 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
>>> On 2/18/25 5:12 AM, Simon Martin wrote:
We've been rejecting this valid code since r8-4571:
==
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, March 5, 2025 11:27 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> extractions [PR118464]
>
This patch introduces acle_sqrt.c in the AArch64 testsuite, verifying
that the new __sqrt and __sqrtf intrinsics emit the expected fsqrt
instructions for double and float arguments.
Coverage for new intrinsics ensures that __sqrt and __sqrtf are
correctly expanded to hardware instructions and do n
This patch introduces two new inline functions, __sqrt and __sqrtf, in
arm_acle.h for AArch64 targets. These functions wrap the new builtins
__builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
providing direct access to hardware instructions without relying on the
standard math lib
This patch changes the `sqrt` builtin definition from `BUILTIN_VHSDF_DF`
to `BUILTIN_VHSDF_HSDF` in `aarch64-simd-builtins.def`, ensuring the
builtin covers half, single, and double precision variants. The redundant
`VAR1 (UNOP, sqrt, 2, FP, hf)` lines are removed, as they are no longer
needed now
On Thu, 6 Mar 2025 at 11:47, Jonathan Wakely wrote:
>
> On Thu, 6 Mar 2025 at 11:36, Giuseppe D'Angelo
> wrote:
> >
> > Hi,
> >
> > On 06/03/2025 12:26, Jonathan Wakely wrote:
> > > The old COW std::string is not usable in constant expressions, so these
> > > new tests fail with -D_GLIBCXX_USE_CX
This change makes the consteval function slightly faster to compile.
Instead of keeping the counts in an array and looping over that array,
we can just keep a sum of how many valid types are present, and check
that it equals the total number of types in the pack. We can also avoid
doing the check e
I trust you'll understand why I haven't yet replied to the roughly
three-dozen messages that came roaring through today. It's been a lot to
absorb.
I will start by saying, "Thank you". I didn't fully understand the
implications of adding 100,000 or so lines of code, especially when our
under
Hi, Henrik, John,
Sorry for my late reply to the thread.
Before I wrote this proposal, I spent quite some time try to understand why
people
from C community and C++ community have so different views on the current syntax
of counted_by.
Then I spent some time to study and compare the variable
On 7 Mar 2025, at 19:12, Yeoul Na wrote:
> Hi Kees,
>
>> On Mar 7, 2025, at 1:38 PM, Kees Cook wrote:
>>
>> On Thu, Mar 06, 2025 at 04:27:49PM -0800, Yeoul Na wrote:
>>> Thanks for writing up the RFC and keeping us in the loop. Are
>>> you planning to add “__self.” to GCC's C++ compiler as wel
On Wed, 29 Jan 2025 at 18:55, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, I suppose this is stage 1 material?
Yes, I think so, since it could impact C++17 programs.
OK for trunk as soon as stage 1 opens though, thanks.
>
> -- >8 --
>
> As a follow-up to r15-1253 and r15-1254.
>
> li
On Tue, Mar 11, 2025 at 06:37:16PM +, Jonathan Wakely wrote:
> I'm guessing this was Jakub's r15-7960-g09c2a0ab94e1e7
Yes, sorry.
I forgot to regenerate config.h.in when changing configure.ac,
and nothing was really using the macro in the C++ sources,
it is only used in configure.tgt.
Commit
On Tue, Mar 11, 2025 at 02:24:26PM -0500, Robert Dubner wrote:
> As described in https://gcc.gnu.org/gitwrite.html, this is my inaugural,
> no-prior-approval-required, is-it-working? --yes-it-is-I-just-did-it patch
> to MAINTAINERS
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 84c0a6b892b..34
LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow
helper to require operator-> to be valid on a const-qualified lvalue.
This affects the constraints for filter_view::_Iterator::operator-> and
join_view::_Iterator::operator-> so that they can only be used if the
underlying iterator
LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to
dereference a std::unique_ptr if that would return a dangling reference.
That can happen with a custom pointer type and a const-qualified
element_type, such that std::add_lvalue_reference_t is a
reference-to-const that could bind
LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
precondition for std::packaged_task::packaged_task(F&&) to match what
the implementation actually requires. We already gave a diagnostic in
the right cases as required by the issue resolution, so strictly
speaking we don't need to do
LWG 4142 (approved in Wrocław, November 2024) made it ill-formed to call
basic_format_parse_context::check_dynamic_spec with an empty template
argument list.
This adds a static_assert to enforce that, and adjusts the tests.
libstdc++-v3/ChangeLog:
* include/std/format
(basic_form
After r15-6660-g45d306a835cb3f865, in some cases
DFP constants would cause an ICE. This is due to
do a mismatch of a few things. The predicate of the move
uses aarch64_valid_fp_move to say if the constant is valid or not.
But after reload/LRA when can_create_pseudo_p returns false;
aarch64_valid_f
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In this testcase, we pass the checks for mismatched new/delete because the
pointer is deleted before it is returned. And then a subsequent evaluation
uses the cached value, but the deleted heap var isn't in
ctx->global->heap_vars anymore, s
Hi Andre!
Am 11.03.25 um 17:13 schrieb Andre Vehreschild:
Hi all,
attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed
expressions. The patch also ensures that once in an image_selector_list no more
regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is
reje
On Linux/x86_64,
456924e078c0312f9a0f07aa829ab2b6fdcf237c is the first bad commit
commit 456924e078c0312f9a0f07aa829ab2b6fdcf237c
Author: Richard Sandiford
Date: Tue Mar 11 15:39:00 2025 +
aarch64: Generalise tbz_2.c
caused
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test f
On Mon, Mar 10, 2025 at 05:34:40PM +0100, Richard Biener wrote:
> Building gcobol with GCC 7 shows
>
> gcc/cobol/except.cc:285:70: sorry, unimplemented: non-trivial
> designated initializers not supported
>
> that needs to be sorted out (post-merge is OK).
cbl_field_data_t data = { .memsize = ca
Hi Thomas!
Am 11.03.25 um 07:13 schrieb Thomas Koenig:
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Committed as r15-7966-g5e9f71254a5276.
Thanks for the review!
Best regards
Thomas
On Sat, 8 Mar 2025, Tejas Belagod wrote:
> On 3/8/25 12:55 AM, Tejas Belagod wrote:
> > On 3/7/25 5:34 PM, Richard Biener wrote:
> >> On Fri, 7 Mar 2025, Tejas Belagod wrote:
> >>
> >>> On 3/7/25 4:38 PM, Richard Biener wrote:
> On Fri, 7 Mar 2025, Tejas Belagod wrote:
>
> > Given a
On Thu, Mar 06, 2025 at 10:49:08PM +0100, Harald Anlauf wrote:
>
> Thanks for the speedy review!
>
It was a bit easier than normal. After I submitted
the PR, I started to poke around in fortran/resolve.cc
to see if I could deal with the issue. I saw that you
grab the PR last night, and left yo
+ John & Félix & Patryk & Henrik
> On Mar 6, 2025, at 1:44 PM, Qing Zhao wrote:
>
> Hi,
>
> Since I sent the patch series for “extend counted_by attribute to pointer
> fields of structure” two months ago, a lot of discussion were invoked both in
> GCC community and CLANG community:
>
> https:
As described in https://gcc.gnu.org/gitwrite.html, this is my inaugural,
no-prior-approval-required, is-it-working? --yes-it-is-I-just-did-it patch
to MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
index 84c0a6b892b..34e2f9f53b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -162,6 +162,7 @@ Ad
On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner wrote:
>
> Richard and Jakub, and everybody else who has offered advice and help
>
> I trust you realize that your message means Jim and I are reaching the top
> of a mountain we've been climbing for several years now.
>
> This is very exciting.
>
> Th
> Am 11.03.2025 um 16:44 schrieb Richard Sandiford :
>
> pr110625_[24].c started failing after r15-1329-gd66b820f392aa9a7,
> which switched to single def-use cycles for single-lane SLP.
> The problem is that we only costed one vector accumulator
> operation for an N-vector cycle.
>
> The prob
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> My/Kees' earlier patches adjusted -Wunterminated-string-initialization
> warning so that it doesn't warn about initializers of nonstring decls
> and that nonstring attribute is allowed on multi-dimensional arrays.
> Unfortunately as this testcas
Hi, Yeoul,
Sorry for my late reply (I just came back from a short vacation).
And thank you for your comments.
I briefly read your comments and questions in this email, I am wondering
whether you read through the following section in my proposal:
Appendix A Scope of variables in C and C++
On 3/10/25 9:57 AM, Jerry D wrote:
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you
please
take another look?
Jerry, where do I find
On Mon, 10 Mar 2025 17:34:40 +0100
Richard Biener wrote:
> index 10a42cb1dd7..8e18ef1 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> ...
> +# user-defined functions for GCOBOL
> +udfdir = $(datadir)/gcobol/udf
> ..
> @@ -4031,7 +4035,9 @@ installdirs:
> $(mkinstalldirs) $(DE
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, a more minimal fix for the PR would be to just special
case the note_vague_linkage_fn calls to not be performed for gnu_inline
functions, if that's a preferable fix this late into stage 4.
-- >8 --
Currently, note_va
Add anchors for the hardbool and uninitialized attributes and then link
directly to them.
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Add @anchor to
hardbool attribute.
(Common Type Attributes): Add @anchor to uninitialized
attribute.
* d
Sandra Loosemore wrote:
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++,
to improve the location information for individual items in an OpenMP
variable list.
LGTM – thanks for the patch, improving the diagnostic and reducing the
differences between C and C++ for when
Alex Coplan writes:
> Hi,
>
> The PR shows us spinning in dce.cc:fast_dce at the start of combine.
> This spinning appears to be because of a disagreement between the fast_dce
> code
> and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
> disagree on the treatment of partia
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Fix grammar in
final sentence of -ftrivial-auto-var-init description.
---
Pushed as obvious.
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/exten
On Linux/x86_64,
68932eeb38f66fbc0c3cf4b77ff7dde8a408f2e4 is the first bad commit
commit 68932eeb38f66fbc0c3cf4b77ff7dde8a408f2e4
Author: Richard Biener
Date: Tue Mar 11 08:40:44 2025 +0100
middle-end/119204 - ICE with strcspn folding
caused
FAIL: c-c++-common/attr-nonstring-14.c -std=g
Richard Sandiford writes:
> Oscar Gustafsson writes:
>> ChangeLog:
>>
>> * doc/extend.texi: Improve example for __builtin_swap16.
>>
>> ---
>>
>> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
>> index ec9bb59900c..83f6e45170b 100644
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/exten
On 11/03/25 12:54 -0400, Patrick Palka wrote:
Hmm good point -- while the to_input_view iterator is always move-only,
it's not always single pass, the latter property is inherited from the
underlying range.
Here's an updated patch that uses std::same_as in the testcase, and
slightly extends the
On Tue, 11 Mar 2025 at 16:57, Christophe Lyon
wrote:
>
> In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> without the Bugzilla component identifier and with no space between
> 'PR' and the number, but git_check_commit.py accepts all forms. The
> patch enforces what we docum
My P3349R1 paper clarifies that we should be able to lower contiguous
iterators to pointers, without worrying about side effects of individual
increment or dereference operations.
libstdc++-v3/ChangeLog:
* include/bits/stl_algobase.h (__nothrow_contiguous_iterator):
Remove.
Hi,
An optimization was added in GDC-12 which sets the TREE_READONLY flag on
all local variables with the storage class `const' assigned. For some
reason, const is also being added by the front-end to `__result'
variables in non-virtual functions, which ends up getting wrong code by
the gimplify
On 3/10/25 05:53, Christophe Lyon wrote:
Hi!
On Fri, 7 Mar 2025 at 23:57, Sandra Loosemore wrote:
gcc/ChangeLog
PR sanitizer/56682
* doc/invoke.texi (Instrumentation Options): Document that -g
is useful with -fsanitize=thread and -fsanitize=address.
Also m
On Thu, Mar 6, 2025 at 11:50 PM James K. Lowden
wrote:
>
> On Wed, 5 Mar 2025 11:43:16 +0100
> Richard Biener wrote:
>
> > > In short, despite not trying to support DESTDIR, we do anyway, by
> > > happy accident. And we are now better informed.
> >
> > Thanks. Checking cobol-patched again I see
Hi Harald and Jerry,
thanks for taking the time to read my false assumptions ;-)
The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer
remapping is wrong. (F2018 §10.2.2.3 paragraph 9). The rhs is neither simply
contiguous nor of rank one and therefore rejected. I spent some
On Mon, 10 Mar 2025 at 13:00, Richard Earnshaw (lists)
wrote:
>
> On 16/01/2025 14:20, Christophe Lyon wrote:
> > When compiling c-c++-common/vector-compare-3.c with
> > -march=armv8.1-m.main+mve+fp.dp -mfloat-abi=hard -mfpu=auto
> > (which enables MVE), we fail to match vcond_mask because operand
Add missing move_constructible && regular_invocable constrains on functor type,
for invocations of `views::zip_transform` without range arguments.
libstdc++-v3/ChangeLog:
* include/std/ranges (_ZipTransform::operator()):
Add `move_constructible` and `regular_invocable` constraints
Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
> > On 10 Mar 2025, at 15:34, Martin Uecker wrote:
> > > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
> > > > > > That said, my preference is still to just give preference to the
> > > > > > field name,
> > > > > > wh
On Mon, Mar 10, 2025 at 03:51:29PM +0100, Konstantinos Eleftheriou wrote:
> Testcases for patterns `((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)`
> and `(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some
> targets, like PowerPC.
>
> This patch moves the optimization to reasso
When we call loongarch_reassoc_shift_bitwise for
_alsl_reversesi_extend, the mask is in DImode but we are trying
to operate it in SImode, causing an ICE.
To fix the issue sign-extend the mask into the mode we want. And also
specially handle the case the mask is extended into -1 to avoid a
miss-op
Hello world,
the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
Regression-tested. OK for trunk?
Best regards
Thomas
Abstract interfaces and dummy arguments ar
> Am 10.03.2025 um 08:24 schrieb Jakub Jelinek :
>
> Hi!
>
> Studying unwind-dw2-btree.h was really hard for me because
> the formatting is wrong or weird in many ways all around the code
> and that kept distracting my attention.
> That includes all kinds of things, including wrong indentatio
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
build_over_call has:
t = build2 (MODIFY_EXPR, void_type_node,
build2 (MEM_REF, array_type, arg0, alias_set),
build2 (MEM_REF, array_type, arg, alias_set));
val
Dear all,
here's a patch that fixes a 15-regression (NULL pointer dereference)
and implements a missed check of SAVE of a COMMON in a BLOCK construct.
Two separate testcases, as the respective error messages occur at
different stages in the frontend.
Regtested on x86_64-pc-linux-gnu. OK for ma
On Mon, Mar 10, 2025 at 5:34 PM Richard Biener
wrote:
>
> On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner wrote:
> >
> > Richard and Jakub, and everybody else who has offered advice and help
> >
> > I trust you realize that your message means Jim and I are reaching the top
> > of a mountain we've b
> Am 10.03.2025 um 08:16 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase shows a bug in unwind-dw2-btree.h.
> In short, the header provides lock-free btree data structure (so no parent
> link on nodes, both insertion and deletion are done in top-down walks
> with some locking of ju
Hi!
I've rushed up the PR117178 multi-dimensional nonstring support. Before
a week off I've just bootstrapped/regtested the actual change, so
handle_nonstring_attribute/get_attr_nonstring_decl adjustments after playing
with simple short tests and left the testcases for the next day, where I've
ba
On Mon, Mar 10, 2025 at 7:07 PM James K. Lowden
wrote:
>
> On Mon, 10 Mar 2025 17:34:40 +0100
> Richard Biener wrote:
>
> > index 10a42cb1dd7..8e18ef1 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > ...
> > +# user-defined functions for GCOBOL
> > +udfdir = $(datadir)/gcobol/ud
On Tue, Mar 11, 2025 at 9:58 AM Richard Sandiford
wrote:
>
> Andrew Pinski writes:
> > After r15-6660-g45d306a835cb3f865, in some cases
> > DFP constants would cause an ICE. This is due to
> > do a mismatch of a few things. The predicate of the move
> > uses aarch64_valid_fp_move to say if the co
On Tue, Mar 11, 2025 at 5:54 PM Patrick Palka wrote:
> On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Mar 11, 2025 at 5:04 PM Patrick Palka wrote:
> > On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
> >
> > >
> > >
> > > On Mon, Mar 10, 2025 at 11:28 PM Pat
On 3/10/25 1:08 AM, Andre Vehreschild wrote:
Hi Steve and Jerry,
thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you please
take another look?
Jerry, where do I find this check-script? In bin/ nothing ju
On Mon, 2025-03-10 at 19:07 +0100, Richard Biener wrote:
> On Mon, Mar 10, 2025 at 5:34 PM Richard Biener
> wrote:
> >
> > On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner
> > wrote:
> > >
> > > Richard and Jakub, and everybody else who has offered advice and
> > > help
> > >
> > > I trust you re
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I noticed some more properties that we
don't stream or check properly. This patch adds the ones we were
missing, and adds checks that the values don't clash wit
On Mon, Mar 10, 2025 at 7:52 AM Konstantinos Eleftheriou
wrote:
>
> Testcases for patterns `((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)`
> and `(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some
> targets, like PowerPC.
>
> This patch moves the optimization to reassoc. Doing
On Tue, 25 Feb 2025, Maciej W. Rozycki wrote:
> Address this issue by recursing into COMPONENT_REF tree nodes until the
> outermost one has been reached, which is supposed to be a MEM_REF one,
> accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha:
> Also use tree information
We are not supposed to diagnose missing input files.
Pushed.
gcc/cobol/
* gcobolspec.cc (lang_specific_driver): For OPT_print_* do
not error on no input files.
---
gcc/cobol/gcobolspec.cc | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/cobol/gcobolspec.cc b/
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++,
to improve the location information for individual items in an OpenMP
variable list.
gcc/c/ChangeLog
PR c/118579
* c-parser.cc (c_parser_omp_variable_list): Capture location
information when KIND is
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> When we know libgcobol is unsupported on 32-bit arches, we should just say
> so in configure.tgt, the same way as on other targets.
>
> Tested on x86_64-linux with --enable-languages=c,c++,cobol, ok for trunk?
OK.
Thanks,
Richard.
> 2025-03-
Andrew Pinski writes:
> After r15-6660-g45d306a835cb3f865, in some cases
> DFP constants would cause an ICE. This is due to
> do a mismatch of a few things. The predicate of the move
> uses aarch64_valid_fp_move to say if the constant is valid or not.
> But after reload/LRA when can_create_pseudo_
In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
without the Bugzilla component identifier and with no space between
'PR' and the number, but git_check_commit.py accepts all forms. The
patch enforces what we document.
Note that this would reject a few of the recent commits.
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Mar 11, 2025 at 5:04 PM Patrick Palka wrote:
> On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka
> wrote:
> > Tested on x86_64-pc-linux-gnu, do
Implement visit_format_arg and basic_format_arg::visit function,
in terms of _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified as standard
into the handle. This affects __in128, unsigned __in128,
PowerPC specific __iee128 and __ibm128, and _
gcc.target/aarch64/sve/pred-not-gen-[14].c started failing after
r15-268-g9dbff9c05520a74e, but we didn't look at it in time for
GCC 15. This patch marks the failures as expected for now.
We should revisit for GCC 16.
See the PR for some discussion about what a GCC 16 fix might
look like.
Tested
Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
Hi Thomas,
looks good to me as well. Thanks for the patch.
Committed as r15-7964.
Thanks Harald and Andre!
Best regards
Thomas
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_to_input): Def
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:45:09AM +0100, Andreas Schwab wrote:
> > On Mär 11 2025, Jakub Jelinek wrote:
> >
> > > --- libgcobol/configure.tgt.jj2025-03-11 09:18:22.133128278 +0100
> > > +++ libgcobol/configure.tgt 2025-03-11 09:53:32.20895920
On Tue, Mar 11, 2025 at 5:04 PM Patrick Palka wrote:
> On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka
> wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeL
On Tue, 2025-03-11 at 11:47 -0400, David Malcolm wrote:
> This patch changes the output on the simple test I tried from:
>
> $ ./gcobol -B. hello.cob -S
> hello.cob:2:8: error: syntax error, unexpected NAME, expecting
> FUNCTION or PROGRAM-ID
> 2 | porgram-id. hello.
> | ^
r14-7202-gc8ec3e1327cb1e added vld1xN and vst1xN intrinsics and some
tests on arm, but didn't enable some existing tests.
Since these tests are shared with aarch64, this patch replaces the
'dg-skip-if "unimplemented" { arm*-*-* }' directives with:
dg-require-effective-target arm_neon_ok { target a
On Tue, Mar 11, 2025 at 01:24:53PM +0100, Jakub Jelinek wrote:
> Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change.
> Looking in more detail, the way e.g. libsanitizer/configure.tgt works is
> that it is sourced twice, once at toplevel and there it just sets
> UNSUPPORTED=1 fo
Hi!
The following testcase takes very long time to compile, because
skip_simple_arithmetic decides to first call tree_invariant_p on
the second argument (and indirectly recurse there). I think before
canonicalization of operands for commutative binary expressions
(and for non-commutative ones alw
Is it okay to backport below patch and r15-7890-gb7f5d911480 to releases/gcc-14?
Kind regards,
Torbjörn
On 2025-03-11 12:06, Richard Earnshaw wrote:
GCC will complain if the -mcpu flag specifies a different architecture
to that specified in -march, but if the floating-point ABI is "soft",
then
Hi all,
attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed
expressions. The patch also ensures that once in an image_selector_list no more
regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is
rejected, because the 5 must not come after any of (STAT, TEAM, T
pr110625_[24].c started failing after r15-1329-gd66b820f392aa9a7,
which switched to single def-use cycles for single-lane SLP.
The problem is that we only costed one vector accumulator
operation for an N-vector cycle.
The problem seems to have been latent, and meant that we also
only costed one FA
On Fri, Feb 28, 2025 at 10:06:49AM +0100, Richard Biener wrote:
> > I've done 3 x86_64-linux and i686-linux bootstraps/regtests, each time
> > with the 3rd patch to gather statistics on number of successful ICF function
> > merges, and once with no further patches, once with the first patch and
> >
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_to_input): Def
This patch changes the output on the simple test I tried from:
$ ./gcobol -B. hello.cob -S
hello.cob:2:8: error: syntax error, unexpected NAME, expecting FUNCTION or
PROGRAM-ID
2 |porgram-id. hello.
|^
cobol1: error: failed compiling hello.cob
to:
$ ./gcobol -B. hello.
Another problem in pr110625_[24].c was that the latency calculations
were ignoring VEC_PERM_EXPRs that had no associated stmt_vec_info.
Such VEC_PERM_EXPRs are common and expected for SLP these days.
After this change, the number of general ops in the testcases seems
to be accurate apart from one
1 - 100 of 175 matches
Mail list logo
