Hi!
The PR119204 r15-7955 fix caused some regressions.
The problem is that the fold_builtin* APIs document that expr is
either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
can crash e.g. during constexpr evaluation etc.
As can be seen in the surrounding patch, for the neighbouring b
Hi, Monk Chiang
I noticed that at -O0, static functions are emitting lpad instructions, whereas
they do not at -O2. I'm not sure if this is expected behavior.
Upon further investigation, I found that c_node->only_called_directly_p()
returns
false, which is caused by force_output being set to 1.
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > 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 "r
On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely wrote:
> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski wrote:
> >
> >
> >
> > On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely
> wrote:
> >>
> >> This change makes the consteval function slightly faster to compile.
> >> Instead of keeping the coun
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> In PR117262 David was asking for better documentation of RAW_DATA_CST
> and in the review of the PR119076 patch Jason was asking for that as well.
>
> Here is an attempt to do so.
>
> Ok for trunk?
OK.
Richard.
> 2025-03-12 Jakub Jelinek
On Wed, 12 Mar 2025, Tejas Belagod wrote:
> On 3/10/25 7:21 PM, Richard Biener wrote:
> > 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
> I'm not opposed to refactoring but what's the reason for it? We have a large
> number of similar tests that also include all possible types. And aren't all
> the tests you touch FAILing anyway right now? (Due to the combine change...)
Yes, the cond_widen_complicate-3 need some tweak for the
With the COBOL: Frontend (commit 3c5ed996a) came a lang.opt.urls,
which is different from what regenerate-opt-urls.py generates. Make
the CI bot happy by regenerating it.
Longer term, the COBOL docs need to be sorted out (see e.g. PR119227)
and then perhaps regenerate-opt-urls.py adjusted so that
On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:
On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely wrote:
On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski wrote:
>
>
>
> On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely
wrote:
>>
>> This change makes the consteval function slightly faster to compil
On Tue, Mar 11, 2025 at 5:58 PM 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 doc
The build currently fails on MacOS even when the Cobol front-end and
libgcobol builds are disabled.
The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
which somehow makes clang unhappy about the include order:
error: tried including but didn't find libc++'s
header. This
On Fri, Feb 14, 2025 at 08:21:39PM +0800, Xi Ruoyao wrote:
> +(define_expand "dot_prod"
> + [(match_operand: 0 "register_operand" "=f,f")
> + (match_operand:IVEC 1 "register_operand" " f,f")
> + (match_operand:IVEC 2 "register_operand" " f,f")
> + (match_operand: 3 "r
On Wed, 12 Mar 2025 at 07:38, Tomasz Kaminski wrote:
>
>
>
> On Tue, Mar 11, 2025 at 10:26 PM Jonathan Wakely wrote:
>>
>> 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
>Could you add a test for functor that is only rvalue-callable (only
>operator() &&).
>There was discussion about this case on reflector, so I think it would be
>good to document that they are not supported.
Like this?
LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
preconditi
Hi,
On Wed, Mar 12, 2025 at 04:19:10AM +, Sam James wrote:
> 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
> ad
On Wed, 12 Mar 2025 at 10:47, Tomasz Kaminski wrote:
>
>
>
> On Wed, Mar 12, 2025 at 11:06 AM Jonathan Wakely wrote:
>>
>> On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:
>> >On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely wrote:
>> >
>> >> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski wrote:
>
Import the new 2025a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).
libstdc++-v3/ChangeLog:
* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date for leap seconds list.
* src/c++20/tzdata.z
On Wed, Mar 12, 2025 at 11:06 AM Jonathan Wakely wrote:
> On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:
> >On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely
> wrote:
> >
> >> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Mar 11, 2025 at 11:46 PM Jona
On Wed, Mar 12, 2025 at 12:09:44PM +0100, Mark Wielaard wrote:
> Hi David,
>
> On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> > FWIW gcc/cobol/lang.opt.urls has some D-specific things that look like
> > copy-and-paste cruft, but hopefully it won't cause problems.
>
> And some Fo
Hi,
This patch merges the D standard library with upstream phobos 0faae92d6.
Synchronizing with the upstream release of v2.111.0-beta.1.
Phobos changes:
- Import phobos v2.111.0-beta.1.
- Added `bitCast' function to `std.conv'.
- Added `readfln' and `File.readfln' functi
On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:
> On 3/10/25 9:50 AM, Nathaniel Shead wrote:
> > 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
On 3/7/25 6:00 AM, Nathaniel Shead wrote:
On Fri, Mar 07, 2025 at 09:48:27PM +1100, Nathaniel Shead wrote:
On Thu, Mar 06, 2025 at 11:20:59AM -0500, Jason Merrill wrote:
On 2/9/25 6:38 AM, Nathaniel Shead wrote:
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
Tested on x86_64
When doing strided SLP vectorization we use the wrong alignment for
the possibly piecewise access of the vector elements for loads and
stores. While we are carefully using element aligned loads and
stores that isn't enough for the case the original scalar accesses
are packed. The following instea
On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
> On 3/10/25 9:52 AM, Nathaniel Shead wrote:
> > 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 propertie
From: Pan Li
Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together. Then we can
easily reduce the range when asm check fails.
The below test suites are passed locally, let's wait online CI says.
* The rv64gcv fully regress
On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> On Wed, 12 Mar 2025 at 08:05, Richard Biener
> wrote:
> >
> > On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> > wrote:
> > >
> > > In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> > > without the Bugzilla
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 _
Subregs that only change the mode of an operand (ie don't change the
size) should be safe for the VPR register. If we don't permit them
we may end up with some redundant copy instructions.
gcc:
PR target/115439
* config/arm/predicates.md (vpr_register_operand): Allow type-punning
Hi Richard,
> That was also what I was trying to say. In the worst case, the linked
> object has to meet the requirements of the lowest common denominator.
>
> And my supposition was that that isn't a property of static vs dynamic.
But it is. Dynamic linking supports mixing different code models
On Wed, Mar 12, 2025 at 11:02 AM Jonathan Wakely wrote:
>
> On Wed, 12 Mar 2025 at 09:55, Jakub Jelinek wrote:
> >
> > On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> > > On Wed, 12 Mar 2025 at 08:05, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Mar 11, 2025 at 5:58 PM
On 11/03/2025 17:39, Richard Sandiford wrote:
> 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_comput
On Wed, Mar 12, 2025 at 09:01:17AM -0400, Jason Merrill wrote:
> Why not use new_ctx for this instead of creating another copy?
>
> I would think once we see that we have an immediate function, we want to go
> ahead and set ctx->manifestly_const_eval and new_call->manifestly_const_eval
> to true.
Hi Thomas,
I think this patch produced a regression:
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9)
When I revert your patch and test again, above fails do not occur. Could you
please i
The following makes vs_external_reference behave like documented,
declare a variable defined elsewhere which means not setting
TREE_STATIC but DECL_EXTERNAL.
Built on x86_64-unknown-linux-gnu, tested with the cobol.dg
testsuite (which doesn't mean much). The removed comment mentions
'stderr', pos
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> >
> > > 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
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 12, 2025 03:23
> To: Robert Dubner
> Cc: Richard Biener ; Iain Sandoe
> ; GCC Patches ;
> jklow...@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
>
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Rob
On Wed, 2025-03-12 at 12:09 +0100, Mark Wielaard wrote:
> Hi David,
>
> On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> > FWIW gcc/cobol/lang.opt.urls has some D-specific things that look
> > like
> > copy-and-paste cruft, but hopefully it won't cause problems.
>
> And some Fortr
Hi Robert,
On Wed Mar 12, 2025 at 2:12 PM CET, Robert Dubner wrote:
>
>
>> -Original Message-
>> From: Simon Martin
>> Sent: Wednesday, March 12, 2025 06:27
>> To: gcc-patches@gcc.gnu.org
>> Cc: rdub...@symas.com
>> Subject: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore
>
On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>
> > 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 introducin
This commit has changed int __attribute__ ((__mode__ (__word__))) on s390
-m31 from int to long long. That introduces a glibc testsuite failure -
the glibc testsuite verifies the expected C++ name mangling of various
types, including register_t (which is defined with that attribute).
https://s
Hi Harald,
thanks for the review. Committed with the requested changes (intrinsic module
ISO_FORTRAN_ENV and indexes -> indices in the description) as
gcc-15-7997-gbaa9b2b8d2e
I haven't added F2023 NOTIFY= image-selector yet, because at the moment I am
striving to get F2018 more complete.
Thanks
On 3/12/25 11:38 AM, Jakub Jelinek wrote:
On Wed, Mar 12, 2025 at 09:01:17AM -0400, Jason Merrill wrote:
Why not use new_ctx for this instead of creating another copy?
I would think once we see that we have an immediate function, we want to go
ahead and set ctx->manifestly_const_eval and new_ca
> On Mar 10, 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,
>> which sidesteps any need for disambiguation syntax and avoids this whole
>> pro
The fix for this depends on much more infrastructure which won't
be done for another few weeks. Pengxuan is working on the fix for GCC 16.
So let's xfail the testcase since it is a minor code quality regression.
we get:
```
moviv0.2s, 0
ins v0.h[0], w0
```
vs what we should
On Wed, 12 Mar 2025 at 09:55, Jakub Jelinek wrote:
>
> On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> > On Wed, 12 Mar 2025 at 08:05, Richard Biener
> > wrote:
> > >
> > > On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> > > wrote:
> > > >
> > > > In https://gcc.gnu.org/con
On Wed, Mar 12, 2025 at 12:28:58AM -0400, Jason Merrill 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, arra
On 3/10/25 7:21 PM, Richard Biener wrote:
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:
This test has been failing since gcc-6. The test was always very
fragile anyway since it relied on an auto-inc being created and then
split by the subreg2 (later the subreg3) pass. But the code to get
precisely these conditions was very long-winded and unlikely to be
immune to other changes in th
在 2025/3/12 下午9:14, Xi Ruoyao 写道:
Structured binding is a C++17 feature but the GCC code base is in C++14.
I couldn't find the description of the standards followed by GCC code in
the document yesterday.
Therefore, I assumed that this standard is the same as the default
standard set durin
On Wed, Mar 12, 2025 at 6:23 PM Lulu Cheng wrote:
>
>
> 在 2025/3/12 下午9:14, Xi Ruoyao 写道:
> > Structured binding is a C++17 feature but the GCC code base is in C++14.
>
> I couldn't find the description of the standards followed by GCC code in
> the document yesterday.
>
> Therefore, I assumed tha
Ping.
On 2/20/25 10:51 AM, Simon Marchi wrote:
> [Note: I don't have push access to gcc, so if approved, please push it
> on my behalf, thanks.]
>
> I need to have a "DW_LANG_* to string" function for a change I'm making
> in binutils-gdb. I'm sending this patch to gcc first, once merged I'll
>
gcc.target/aarch64/sve/pr98119.c has been failing since r15-268.
The test expects pointer alignment to be done with a plain AND,
but that no longer happens.
It was combine that previously generated the ANDs, but I think it's
fair to argue that it isn't combine's job to handle this case.
The test's
Using a combination of rules, we were able to fold
((X >> C1) & C2) * (1 << C1) --> X & (C2 << C1)
if everything was done at the same precision, but we couldn't fold
it if the AND was done at a different precision. The optimisation is
often (but not always) valid for that case too.
This pat
On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski wrote:
>
>
>
> On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely wrote:
>>
>> 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 ho
Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
>
> > On Mar 10, 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
> > > n
On Wed, Mar 12, 2025 at 09:41:01AM -0700, H.J. Lu wrote:
> This caused:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2025-March/081862.html
This should have been fixed with r15-7981 already.
Jakub
On Wed, Mar 12, 2025 at 9:43 AM H.J. Lu wrote:
>
> On Tue, Mar 11, 2025 at 2:58 AM Richard Biener wrote:
> >
> > The following makes sure to convert the folded expression to the
> > original expression type.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Rich
On Wed, 12 Mar 2025, Martin Uecker wrote:
> For a designator
>
> struct foo { int n; } a = { .n = 1 };
>
> we also refer to a member 'n' of an instance 'a' of a structure type.
> The instance is simply implied by the context.
>
> For
>
> struct foo { int n; char *x __counted_by(.n) };
>
> is
Hello,
On Wed, 12 Mar 2025, Martin Uecker wrote:
> > To me, this is clearer. But I am okay with the designator syntax.
>
> I am also okay with __self__ if people have concerns about resuing the
> designator syntax. We could still always drop the requirement for
> writing __self__ later.
So,
On Mon, Mar 10, 2025 at 11:33 PM Henrik Olsson wrote:
>
>
>
> On Mar 10, 2025, at 11:04 PM, Martin Uecker wrote:
>
> Am Montag, dem 10.03.2025 um 19:30 -0400 schrieb John McCall:
>
> On 10 Mar 2025, at 18:30, Martin Uecker wrote:
>
> Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
>
libgcobol/ChangeLog:
* charmaps.cc: Fix typo in comment.
---
Committed as obvious.
libgcobol/charmaps.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcobol/charmaps.cc b/libgcobol/charmaps.cc
index 3b75c08dd2f..561fe230121 100644
--- a/libgcobol/charmaps.cc
++
From: Pan Li
Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together. Then we can
easily reduce the range when asm check fails.
I'm not opposed to refactoring but what's the reason for it? We have a large
number of simil
Applying to trunk.
-- 8< --
Previously, if the common ancestor of the two paths is / we would print the
absolute second argument, but this PR asks for a relative path in that case
as well, which makes sense for the libstdc++.modules.json use case.
PR libstdc++/119081
contrib/ChangeLog:
On 3/7/25 11:53 AM, Jakub Jelinek wrote:
Hi!
Since Marek's r14-4140 which moved immediate invocation evaluation
from build_over_call to cp_fold_r, the following testcase is miscompiled.
The a = foo (bar ()); case is actually handled right, that is handled
in cp_fold_r and the whole CALL_EXPR is
Hi,
On Thu Mar 6, 2025 at 8:06 PM CET, Simon Martin wrote:
> 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:
> -Original Message-
> From: Simon Martin
> Sent: Wednesday, March 12, 2025 06:27
> To: gcc-patches@gcc.gnu.org
> Cc: rdub...@symas.com
> Subject: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore
> MacOS build
>
> The build currently fails on MacOS even when the Cobol fro
On 3/7/25 11:40 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
OK.
-- >8 --
The r12-8258 fix assumes that DECL_CONTEXT of 'pack' in
check_for_bare_parameter_packs is going to be an operator()
but as this test shows, it can be empty.
PR
On 3/6/25 2:06 PM, Simon Martin wrote:
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 si
On Tue, 11 Mar 2025 at 12:22, Tomasz Kamiński wrote:
>
> Floating points types _Float16, _Float32, _Float64, and bfloat16,
> can be formatted only if std::to_chars overloads for such types
> where provided. Currently this is only the case for architectures
Spelling: "were provided"
With that fixe
Removing extraneous/erroneous entries, leaving me just Front End
Maintainers
I pushed this change to origin/master
diff --git a/MAINTAINERS b/MAINTAINERS
index 34e2f9f53b7..5b3fe407860 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -277,7 +277,6 @@ check in changes outside of the parts of the comp
gcc.target/aarch64/sve/pre_cond_share_1.c started failing after
r15-276-gbed6ec161be8c5ca. However, that was incidental.
The test's inner loop is duplicated by -fswitch-loops and
that patch happened to change the copy of the loop that was
not the original focus of the test.
The test was added as
Structured binding is a C++17 feature but the GCC code base is in C++14.
gcc/ChangeLog:
PR target/119238
* config/loongarch/simd.md (dot_prod):
Stop using structured binding.
---
Ok for trunk?
gcc/config/loongarch/simd.md | 14 --
1 file changed, 8 insertion
Hi!
In PR117262 David was asking for better documentation of RAW_DATA_CST
and in the review of the PR119076 patch Jason was asking for that as well.
Here is an attempt to do so.
Ok for trunk?
2025-03-12 Jakub Jelinek
* tree.def (RAW_DATA_CST): Document meaning of NULL RAW_DATA_OWNER
On Wed, Mar 12, 2025 at 11:28 AM Simon Martin wrote:
>
> The build currently fails on MacOS even when the Cobol front-end and
> libgcobol builds are disabled.
>
> The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
> which somehow makes clang unhappy about the include order:
>
On 3/10/25 9:50 AM, Nathaniel Shead wrote:
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 lat
On 3/12/25 10:43 AM, Nathaniel Shead wrote:
On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:
On 3/10/25 9:50 AM, Nathaniel Shead wrote:
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
Hi Andre,
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9)
When I revert your patch and test again, above fails do not occur. Could you
please investigate, if I am right?
Jep, I missed
On Tue, 11 Mar 2025, Robert Dubner wrote:
> 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 re
On 12/03/25 15:39 +0100, Tomasz Kamiński wrote:
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 __in1
Hi David,
On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> FWIW gcc/cobol/lang.opt.urls has some D-specific things that look like
> copy-and-paste cruft, but hopefully it won't cause problems.
And some Fortran stuff. The autoregen bot currently flags it with the
following diff:
d
Am Mittwoch, dem 12.03.2025 um 16:58 + schrieb Joseph Myers:
> On Wed, 12 Mar 2025, Martin Uecker wrote:
>
> > For a designator
> >
> > struct foo { int n; } a = { .n = 1 };
> >
> > we also refer to a member 'n' of an instance 'a' of a structure type.
> > The instance is simply implied by th
On Tue, 10 Dec 2024 at 00:59, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> The attached patch fixes a compile error when converting a weak_ptr of
> array type to a compatible type, for instance:
>
> std::weak_ptr wptr;
> std::weak_ptr wptr2 = wptr; // ERROR
>
> https://gcc.godbolt.org/z/EWYb73Mvf
>
> T
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The PR119204 r15-7955 fix caused some regressions.
> The problem is that the fold_builtin* APIs document that expr is
> either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
> can crash e.g. during constexpr evaluation etc.
>
> As c
On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> 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-leve
On Wed, Mar 12, 2025 at 12:04:52AM -0700, Andrew Pinski wrote:
> I think it would be useful to add the C testcase that fails during DOM
> from PR 119226 since that is another path to get the ICE.
I've committed the patch already.
Feel free to commit the testcase for it (preferably a little bit cle
On Tue, Mar 11, 2025 at 10:14 PM Jonathan Wakely wrote:
> 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.
>
> lib
On Tue, Mar 11, 2025 at 10:22 PM Jonathan Wakely wrote:
> 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
On Tue, Mar 11, 2025 at 10:26 PM Jonathan Wakely wrote:
> 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
On Wed, Mar 12, 2025 at 12:01 AM Jakub Jelinek wrote:
>
> Hi!
>
> The PR119204 r15-7955 fix caused some regressions.
> The problem is that the fold_builtin* APIs document that expr is
> either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
> can crash e.g. during constexpr evaluation e
On Tue, Mar 11, 2025 at 10:28 PM Jonathan Wakely wrote:
> 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::o
On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely wrote:
> 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 tota
Hi!
On Wed, Mar 12, 2025 at 08:31:27AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 12, 2025 at 12:04:52AM -0700, Andrew Pinski wrote:
> > I think it would be useful to add the C testcase that fails during DOM
> > from PR 119226 since that is another path to get the ICE.
>
> I've committed the patch
Thanks for the review!
Andrew Pinski writes:
> On Wed, Mar 12, 2025 at 12:00 PM Richard Sandiford
> wrote:
>>
>> Using a combination of rules, we were able to fold
>>
>> ((X >> C1) & C2) * (1 << C1) --> X & (C2 << C1)
>>
>> if everything was done at the same precision, but we couldn't fold
>
On Wed, Mar 12, 2025 at 1:38 PM Richard Sandiford
wrote:
>
> Thanks for the review!
>
> Andrew Pinski writes:
> > On Wed, Mar 12, 2025 at 12:00 PM Richard Sandiford
> > wrote:
> >>
> >> Using a combination of rules, we were able to fold
> >>
> >> ((X >> C1) & C2) * (1 << C1) --> X & (C2 << C
Here's an updated version of this patch which adds a testcase to the
DejaGnu test suite, using *<< and *>> for a multiline comment (used to
express a fragment of the expected output on stderr).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, but
I *haven't* tested this patch with th
* François Dumont:
> + // Get hash code for a node that comes from another _Hashtable.
> + // Reuse a cached hash code if the hash function is stateless,
> + // otherwise recalculate it using our own hash function.
> + __hash_code
> + _M_hash_code_ext(const __node_value_ty
On Wed, 12 Mar 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> perhaps 13?
>
> N.B. the use of a constrained auto instead of a separate static_assert
> in the testcase is unfortunate but I opted for local consistency for
> now.
>
> -- >8 --
>
> U
在 2025/3/13 上午10:36, Andrew Pinski 写道:
On Wed, Mar 12, 2025 at 6:23 PM Lulu Cheng wrote:
在 2025/3/12 下午9:14, Xi Ruoyao 写道:
Structured binding is a C++17 feature but the GCC code base is in C++14.
I couldn't find the description of the standards followed by GCC code in
the document yesterda
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
perhaps 13?
N.B. the use of a constrained auto instead of a separate static_assert
in the testcase is unfortunate but I opted for local consistency for
now.
-- >8 --
Unlike for span and empty_view, the range_reference_t of
ref_vie
On Wed, 12 Mar 2025, Patrick Palka wrote:
> On Wed, 12 Mar 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> > perhaps 13?
> >
> > N.B. the use of a constrained auto instead of a separate static_assert
> > in the testcase is unfortunate but I op
1 - 100 of 112 matches
Mail list logo
