Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
-- >8 --
In the linked testcase, an ICE occurs because when reading the
(duplicate) function definition for _M_do_parse from module Y, the local
type definitions have already been streamed from module X and setup as
regular backr
> Hi,
>
> PR 118138 and quite a few duplicates that it has acquired in a short
> time show that even though we are careful to make sure we do not loose
> any bits when newly allowing type conversions in jump-functions, we
> still need to perform the fold conversions during IPA constant
> propagati
On Thu, Jan 09, 2025 at 03:28:28PM +0100, Jakub Jelinek wrote:
> So like this?
Thomas mentioned bad wording in a private mail. Here is a better patch:
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
the opt
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, January 9, 2025 3:09 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Fix costing of emulated gathers/scatters
> [PR118188]
>
> Tamar Chri
On Wed, 8 Jan 2025, Jason Merrill wrote:
> On 12/21/24 11:35 AM, Simon Martin wrote:
> > When erroring out due to an incomplete type, we add a contextual note
> > about the type. However, when the error is suppressed by
> > -Wno-template-body, the note remains, making the compiler output quite
> >
Hi Jakub,
Yes, that is what I had in mind. Being German I don't see any problem with the
explanation, but that is better judged by a native English speaker.
Is the send patch hunk intentional where only indentation is changed? I haven't
applied it though.
Thanks for the patch,
Andre
On
On Thu, Jan 09, 2025 at 06:12:51PM +0100, Andre Vehreschild wrote:
> Yes, that is what I had in mind. Being German I don't see any problem with the
> explanation, but that is better judged by a native English speaker.
>
> Is the send patch hunk intentional where only indentation is changed? I
> h
Hi Akram
> On 8 Jan 2025, at 16:23, Akram Ahmad wrote:
>
> Hi Kyrill,
>
> Thanks for the feedback on V2. I found a pattern which works for
> the open-coded signed arithmetic, and I've implemented the other
> feedback you provided as well.
>
> I've send the modified patch in this thread as the
On Thu, 9 Jan 2025, Zhou Zhao wrote:
>
> 在 2025/1/9 下午3:33, Richard Biener 写道:
> > On Thu, 9 Jan 2025, Zhou Zhao wrote:
> >
> >> 在 2025/1/8 下午6:30, Richard Biener 写道:
> >>> On Wed, 8 Jan 2025, Zhou Zhao wrote:
> >>>
> 在 2025/1/8 下午5:04, Richard Biener 写道:
> > On Wed, 8 Jan 2025, Zhou Zha
On 08/01/2025 21:47, Thiago Jung Bauermann wrote:
> "Richard Earnshaw (lists)" writes:
>
>> On 27/12/2024 21:47, Thiago Jung Bauermann wrote:
>>> In 32-bit Arm assembly, the @ character is the start of a comment so
>>> the section type needs to use the % character instead.
>>>
>>> configure.ac at
在 2025/1/9 下午3:33, Richard Biener 写道:
On Thu, 9 Jan 2025, Zhou Zhao wrote:
在 2025/1/8 下午6:30, Richard Biener 写道:
On Wed, 8 Jan 2025, Zhou Zhao wrote:
在 2025/1/8 下午5:04, Richard Biener 写道:
On Wed, 8 Jan 2025, Zhou Zhao wrote:
在 2025/1/7 下午10:45, Richard Biener 写道:
On Thu, 2 Jan 2025, 赵洲
On 22/12/2024 15:27, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> When the test was initially created, -fcommon was the default, but in
> commit r10-4867-g6271dd984d7 the default value changed to -fno-common.
> This change made the test start failing. To counter the ove
On 27/12/2024 08:32, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> The implementation of the functions in the test case expects there to be
> a few arguments to the helper functions, but the prototype does not have
> any arguments at all. Align these to avoid these errors:
>
> .../pr59858.
We segfault upon the following invalid code
=== cut here ===
template struct S {
friend void foo (int a = []{}());
};
void foo (int a) {}
int main () {
S<0> t;
foo ();
}
=== cut here ===
The problem is that we end up with a LAMBDA_EXPR callee in
set_flags_from_callee, and dereference its N
Hello world,
This patch fixes and reorganizes dumping C prototypes. It makes the
following changes:
- BIND(C) types are now always output before any global symbols
- CFI_cdesc_t is issued for assumed shape and assumed rank arguments.
- BIND(C,NAME="...") entities were no
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 8d31ddfcffb..826f
Hi!
On 2024-12-03T12:32:35-0700, Jeff Law wrote:
> Jakub noted that these tests were using dg-skip-if directives that
> implied the tests were expected to run under multiple optimization
> options, which means they probably should be in gcc.dg/torture rather
> than in the gcc.dg directory.
>
>
On 9 Jan 2025, at 20:00, Marek Polacek wrote:
> On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
>> On Wed, 8 Jan 2025, Jason Merrill wrote:
>>
>>> On 12/21/24 11:35 AM, Simon Martin wrote:
When erroring out due to an incomplete type, we add a contextual
note
about th
I am going to trim back some of the older stuff.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, January 7, 2025 08:32
> To: Robert Dubner
> Cc: jklow...@symas.com; Joseph Myers ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH] COBOL 3/8 gen: GENERIC interface
>
> On Mon,
On 1/9/25 2:11 PM, David Malcolm wrote:
Here's v2 of the patch. I only changed the C++ parts, for the nits
identified by Marek. I didn't attempt to add coverage for the objc++
method stuff.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Are the C++ parts OK for trunk? (Joseph
On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
> On Wed, 8 Jan 2025, Jason Merrill wrote:
>
> > On 12/21/24 11:35 AM, Simon Martin wrote:
> > > When erroring out due to an incomplete type, we add a contextual note
> > > about the type. However, when the error is suppressed by
> > >
On 1/9/25 10:48 AM, Qing Zhao wrote:
I think Jeff's patch is not reasonable since it boils down to not diagnose
-Warray-bounds but instead remove those stmts.
If these stmts are dead-code that are generated by compiler optimization (NOT
from source code),
removing them before diagnosis is
Here's v2 of the patch. I only changed the C++ parts, for the nits
identified by Marek. I didn't attempt to add coverage for the objc++
method stuff.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Are the C++ parts OK for trunk? (Joseph already approved the C parts)
Thanks
Dave
I spent way too long poking at various adjustments of this; here's what I
settled on for GCC 15.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When the program requests a conversion to a typedef, let's try harder to
remember the new name.
Torbjörn's original patch changed the type of
> On Jan 9, 2025, at 14:10, Jeff Law wrote:
>
>
>
> On 1/9/25 10:48 AM, Qing Zhao wrote:
>
>>>
>>> I think Jeff's patch is not reasonable since it boils down to not diagnose
>>> -Warray-bounds but instead remove those stmts.
>> If these stmts are dead-code that are generated by compiler op
101 - 125 of 125 matches
Mail list logo
