Hi,
This patch merges the D front-end and run-time library with upstream dmd
5f7552bb28, and standard library with phobos 67a47cf39.
Synchronizing the latest bug fixes in the upcoming v2.103.0 release.
D front-end changes:
- Import dmd v2.103.0-rc.1.
D runtime changes:
- Impor
This section of the GCC manual had some issues with lines in the example
overflowing into the right margin of the PDF-format document, but as I
looked at it more closely I also saw that it was full of missing or
incorrect Texinfo markup, too. I've cleaned it up thusly.
-Sandracommit 7ffbc74c8
I noticed when looking at other things last week that there were a whole
bunch of too-long lines overflowing into the right margin in the PDF
version of the GCC manual. This patch fixes some of them. There are
still a whole bunch of especially bad ones in the diagnostic message
formatting exa
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature mode of
the registers to move the content for the assignment.
As the example co
The issue of suboptimal code exists even for integer return value and not just
bool return value. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784#c9
So the patch would need to take care of integer return values too.
On 16/03/23 10:50 am, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
Hi,
This patch is fixing an issue about parameter accessing if the
parameter is struct type and passed through integer registers, and
there is floating member is accessed. Like below code:
typedef struct DF {double a[4]; long l; } DF;
double foo_df (DF arg){return arg.a[3];}
On ppc64le, with tru
Hi Richard,
在 2023/3/16 18:36, Richard Biener 写道:
> On Thu, Mar 16, 2023 at 10:04 AM HAO CHEN GUI wrote:
>>
>> Hi Richard,
>>
>> 在 2023/3/16 15:57, Richard Biener 写道:
>>> So this is one way around the lack of CSE/PRE of constant operands. I'd
>>> argue that a better spot for this _might_ be LRA
Pushed.
Gerald
---
htdocs/readings.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 3cdc47a9..6813b84f 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -310,8 +310,8 @@ names.
z/Architecture (S/390)
On Sat, 10 Mar 2018, Segher Boessenkool wrote:
>> It appears this link at atmel.com has been taken down without
>> what appears a replacement, so I applied the patch below.
> Atmel was bought by Microchip some two years ago... Maybe
> https://www.microchip.com/design-centers/8-bit/microchip-avr-mc
With this the Modula-2 manual -- quite impressive, but the way -- is now
finally reachable from our /onlinedocs page.
Gerald
---
htdocs/onlinedocs/index.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
i
On Thu, 16 Mar 2023, Gaius Mulley wrote:
>> Does maintainer-scripts/update_web_docs_git require an update to cover
>> Modula-2 and actually build the manual we are now linking to
> Apologies I was going to ask about these links. I've updated the m2
> subtree with target documentation independent
Hello
There's a typo in the common function attribute docs, "nonnul" which this patch
corrects.
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
gcc/ChangeLog
2023-03-16 Jonny Grant
* doc/extend.texi: correct function attribute typo
---
g
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As in 108242, we need to instantiate in the context of the enclosing
function, not after it's gone.
PR c++/105809
gcc/cp/ChangeLog:
* init.cc (get_nsdmi): Split out...
(maybe_instantiate_nsdmi_init): ...this functi
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here we are trying to do name lookup in a deferred instantiation of t() and
failing to find __func__. tsubst_expr already tries to instantiate members
of local classes, but was failing with the partial instantiation of generic
lambdas.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We don't want to call build_offset_ref with an enum.
PR c++/101869
gcc/cp/ChangeLog:
* semantics.cc (finish_qualified_id_expr): Don't try to build a
pointer-to-member if the scope is an enumeration.
gcc/testsuite/
on a structure with a C99 flexible array member being nested in
another structure. (PR77650)
"GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size per
-fstrict-flex-arrays.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-dec
Hi, Joseph, Jakub and Sandra,
Could you please review this patch and let me know whether it???s ready
for committing into GCC13?
The fix to Bug PR101832 is an important patch for kernel security
purpose. it's better to be put into GCC13.
===
These are the
Just to add a bit more color on this one...
It was originally observed (and isolated from)
_ZN11xalanc_1_1027XalanReferenceCountedObject12addReferenceEPS0_ and
reproduces both for AArch64 and RISC-V.
The basic block (annotated with dynamic instructions executed and
percentage of total dynamic inst
8-byte modes should be processed only for TARGET_MMX_WITH_SSE.
gcc/ChangeLog:
* config/i386/i386-expand.cc (expand_vec_perm_pblendv):
Handle 8-byte modes only with TARGET_MMX_WITH_SSE.
(expand_vec_perm_2perm_pblendv): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m
> From: Hans-Peter Nilsson
> Date: Thu, 16 Mar 2023 19:25:05 +0100
> That doesn't seem like a good idea. At a glance the
> *testcode* will be simpler, but the patch will be slightly
> larger
Bah, s/but the patch will be slightly larger/and the patch
will certainly be smaller, but because less i
On Thu, 2023-03-16 at 19:25 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm
> > Date: Thu, 16 Mar 2023 13:55:48 -0400
>
> > On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote:
> > > It's not obvious to me whether considered best to include or
> > > exclude these tests that depen
> On Mar 16, 2023, at 12:53 PM, Jakub Jelinek wrote:
>
> On Thu, Mar 16, 2023 at 04:38:41PM +, Qing Zhao via Gcc-patches wrote:
>>> NO. We have this debate every few years and such.
>>
>> So, what’s the major reason we keep the default that is not IEEE754
>> compliant from the beginning?
> From: David Malcolm
> Date: Thu, 16 Mar 2023 13:55:48 -0400
> On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote:
> > It's not obvious to me whether considered best to include or
> > exclude these tests that depend on structure layout details.
> > If excluding, the obvious alternative
ping
From: Wilco Dijkstra
Sent: 23 February 2023 15:11
To: GCC Patches
Cc: Richard Sandiford ; Kyrylo Tkachov
Subject: [PATCH] libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]
The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Loa
On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote:
> It's not obvious to me whether considered best to include or
> exclude these tests that depend on structure layout details.
> If excluding, the obvious alternative to this patch is then
> to add a top one-liner (to dg-skip-if the test f
On 3/16/23 12:48, Patrick Palka wrote:
When satisfaction_cache::get detects constraint recursion, it asserts
that entry->result is empty. This makes sense when we're initially
detecting/diagnosing recursion from the inner recursive call, but
aftewards from the outer recursive call the recursion
On Thu, Mar 16, 2023 at 04:38:41PM +, Qing Zhao via Gcc-patches wrote:
> > NO. We have this debate every few years and such.
>
> So, what’s the major reason we keep the default that is not IEEE754
> compliant from the beginning?
It is compliant. fusedMultiplyAdd is a standard IEEE 754 ope
When satisfaction_cache::get detects constraint recursion, it asserts
that entry->result is empty. This makes sense when we're initially
detecting/diagnosing recursion from the inner recursive call, but
aftewards from the outer recursive call the recursion error is treated
like any other SFINAE er
On 3/16/23 09:27, Manolis Tsamis wrote:
For this C testcase:
void g();
void f(unsigned int *a)
{
if (++*a == 1)
g();
}
GCC will currently emit a comparison with 1 by using the value
of *a after the increment. This can be improved by comparing
against 0 and using the value before the
> On Mar 16, 2023, at 12:31 PM, Andrew Pinski wrote:
>
> On Thu, Mar 16, 2023 at 9:25 AM Qing Zhao via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> Recently, we discovered some floating point precision diffs when using GCC8
>> to build our
>> application on arm64: After some investigation, it turns
On Thu, Mar 16, 2023 at 9:25 AM Qing Zhao via Gcc-patches
wrote:
>
> Hi,
>
> Recently, we discovered some floating point precision diffs when using GCC8
> to build our
> application on arm64: After some investigation, it turns out that this is due
> to the
> -ffp-contract=fast option that is on
Hi,
Recently, we discovered some floating point precision diffs when using GCC8 to
build our
application on arm64: After some investigation, it turns out that this is due
to the
-ffp-contract=fast option that is on by default. Therefore, we have to
explicitly add
-ffp-contract=off and do a f
On 3/16/23 11:48, Patrick Palka wrote:
On Thu, 16 Mar 2023, Jason Merrill wrote:
On 3/16/23 10:09, Patrick Palka wrote:
On Wed, 15 Mar 2023, Patrick Palka wrote:
On Thu, 9 Mar 2023, Jason Merrill wrote:
On 3/9/23 14:32, Patrick Palka wrote:
On Mon, 6 Mar 2023, Marek Polacek via Gcc-patche
On Thu, 16 Mar 2023, Jason Merrill wrote:
> On 3/16/23 10:09, Patrick Palka wrote:
> > On Wed, 15 Mar 2023, Patrick Palka wrote:
> >
> > > On Thu, 9 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/9/23 14:32, Patrick Palka wrote:
> > > > > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrot
Pinging this patch.
> From: Hans-Peter Nilsson
> Date: Thu, 9 Mar 2023 19:56:16 +0100
>
> It's not obvious to me whether considered best to include or
> exclude these tests that depend on structure layout details.
> If excluding, the obvious alternative to this patch is then
> to add a top one-l
For this C testcase:
void g();
void f(unsigned int *a)
{
if (++*a == 1)
g();
}
GCC will currently emit a comparison with 1 by using the value
of *a after the increment. This can be improved by comparing
against 0 and using the value before the increment. As a result
there is a potentially s
On 3/16/23 04:11, Ajit Agarwal via Gcc-patches wrote:
Hello Richard:
On 16/03/23 3:22 pm, Richard Biener wrote:
On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote:
On 16/03/23 1:44 pm, Richard Biener wrote:
On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote:
Hello Richard:
On 16/0
On Tue, 2023-01-10 at 16:10 +0100, Martin Liška wrote:
> On 1/6/23 14:21, David Malcolm wrote:
> > On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression
> > > tests.
> >
> > Thanks for the patch.
> >
> > I noticed that you mar
On 3/16/23 10:09, Patrick Palka wrote:
On Wed, 15 Mar 2023, Patrick Palka wrote:
On Thu, 9 Mar 2023, Jason Merrill wrote:
On 3/9/23 14:32, Patrick Palka wrote:
On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
When processing a noexcept, constructors aren't elided: build_over_call
h
On Thu, Mar 16, 2023 at 02:11:01PM +, Richard Biener wrote:
> > Let's wait for Honzas opinion.
>
> The following is what I profile-bootstrapped and tested on
> x86_64-unknown-linux-gnu.
>
> Richard.
>
> >From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> From: Richard
On Thu, 16 Mar 2023, Richard Biener wrote:
> On Thu, 16 Mar 2023, Jakub Jelinek wrote:
>
> > On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> > > On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> > >
> > > > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via
> > > > Gcc-pat
On Wed, 15 Mar 2023, Patrick Palka wrote:
> On Thu, 9 Mar 2023, Jason Merrill wrote:
>
> > On 3/9/23 14:32, Patrick Palka wrote:
> > > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> > >
> > > > When processing a noexcept, constructors aren't elided: build_over_call
> > > > has
> > >
On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> > On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> >
> > > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> > > wrote:
> > > > > We could
> > > > > probably keep tra
On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> On Thu, 16 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> > wrote:
> > > > We could
> > > > probably keep tract if any instrumented code was ever inlined into a
> > >
On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> wrote:
> > > We could
> > > probably keep tract if any instrumented code was ever inlined into a
> > > given function and perhaps just start ignoring attributes set on types?
> >
On 16/03/23 4:26 pm, Richard Biener wrote:
> On Thu, Mar 16, 2023 at 11:43 AM Ajit Agarwal wrote:
>>
>>
>>
>> On 16/03/23 4:00 pm, Richard Biener wrote:
>>> On Thu, Mar 16, 2023 at 11:12 AM Ajit Agarwal
>>> wrote:
Hello Richard:
On 16/03/23 3:22 pm, Richard Biener wro
From: Tejas Belagod
This PR optimizes an SVE intrinsics sequence where
svlasta (svptrue_pat_b8 (SV_VL1), x)
a scalar is selected based on a constant predicate and a variable vector.
This sequence is optimized to return the correspoding element of a NEON
vector. For eg.
svlasta (sv
Hi,
Local variables with both non-local references and explicit alignment
did not propagate their alignment to either the closure field or closure
frame type, resulting in the closure being misaligned. This is now
correctly set-up when building the frame type.
Bootstrapped and regression tested o
On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches wrote:
> > We could
> > probably keep tract if any instrumented code was ever inlined into a
> > given function and perhaps just start ignoring attributes set on types?
>
> But ignoring attributes on types makes all indirect
On Thu, Mar 16, 2023 at 11:43 AM Ajit Agarwal wrote:
>
>
>
> On 16/03/23 4:00 pm, Richard Biener wrote:
> > On Thu, Mar 16, 2023 at 11:12 AM Ajit Agarwal
> > wrote:
> >>
> >>
> >> Hello Richard:
> >>
> >> On 16/03/23 3:22 pm, Richard Biener wrote:
> >>> On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarw
On 16/03/23 4:00 pm, Richard Biener wrote:
> On Thu, Mar 16, 2023 at 11:12 AM Ajit Agarwal wrote:
>>
>>
>> Hello Richard:
>>
>> On 16/03/23 3:22 pm, Richard Biener wrote:
>>> On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote:
On 16/03/23 1:44 pm, Richard Biener wrote:
On Thu, Mar 16, 2023 at 10:04 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>
> 在 2023/3/16 15:57, Richard Biener 写道:
> > So this is one way around the lack of CSE/PRE of constant operands. I'd
> > argue that a better spot for this _might_ be LRA (split the constant out if
> > there's a free register av
On Thu, Mar 16, 2023 at 11:12 AM Ajit Agarwal wrote:
>
>
> Hello Richard:
>
> On 16/03/23 3:22 pm, Richard Biener wrote:
> > On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote:
> >>
> >>
> >>
> >> On 16/03/23 1:44 pm, Richard Biener wrote:
> >>> On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal
> >>
Hi Jason
> On 16 Mar 2023, at 03:01, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. As with the array issue, I know you have WIP to
> deal with larger issues, but this seems like a reasonable local fix. Does it
> make sense to you?
Yes, thanks for fixing it,
I believe it will still be
Hello Richard:
On 16/03/23 3:22 pm, Richard Biener wrote:
> On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote:
>>
>>
>>
>> On 16/03/23 1:44 pm, Richard Biener wrote:
>>> On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote:
Hello Richard:
On 16/03/23 1:10 pm, Richard Biener
PING^5
On 2/27/23 10:49, Martin Liška wrote:
> PING^4
>
> On 2/17/23 15:52, Martin Liška wrote:
>> PING^3
>>
>> On 2/1/23 14:13, Martin Liška wrote:
>>> PING^2
>>>
>>> On 1/24/23 14:34, Martin Liška wrote:
PING^1
On 1/10/23 16:10, Martin Liška wrote:
> On 1/6/23 14:21, David Ma
On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote:
>
>
>
> On 16/03/23 1:44 pm, Richard Biener wrote:
> > On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote:
> >>
> >> Hello Richard:
> >>
> >> On 16/03/23 1:10 pm, Richard Biener wrote:
> >>> On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-p
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/vector.md: Fix bug of vmsbc
---
gcc/config/riscv/vector.md | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index a76e8286fe5..c100407d9fa 100644
--- a
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/vector.md: Fix bug of vmsbc
---
gcc/config/riscv/vector.md | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index a76e8286fe5..c100407d9fa 100644
--- a
On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> I've noticed we have instructions on how to update from newer Unicode
> standard, but it didn't mention uname2c.h regeneration.
>
> The following patch mentions that, also mentions that the Copyright years
> of Unicode should be updated and add
Hi!
I've noticed we have instructions on how to update from newer Unicode
standard, but it didn't mention uname2c.h regeneration.
The following patch mentions that, also mentions that the Copyright years
of Unicode should be updated and adds a copy of NameAliases.txt which
is used for uname2c.h g
Hi!
I've noticed I forgot to update copyright years when updating from
Unicode 15.0.0 (and makeucnid.cc had it hopelessly obsolete).
Committed as obvious to trunk.
2023-03-16 Jakub Jelinek
* makeucnid.cc (write_copyright): Update Unicode copyright years
up to 2022.
*
Hi Richard,
在 2023/3/16 15:57, Richard Biener 写道:
> So this is one way around the lack of CSE/PRE of constant operands. I'd
> argue that a better spot for this _might_ be LRA (split the constant out if
> there's a free register available), postreload-[g]cse (CSE the constants) and
> then maybe cp
On 16/03/23 1:44 pm, Richard Biener wrote:
> On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote:
>>
>> Hello Richard:
>>
>> On 16/03/23 1:10 pm, Richard Biener wrote:
>>> On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-patches
>>> wrote:
Hello All:
This patch elim
On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote:
>
> Hello Richard:
>
> On 16/03/23 1:10 pm, Richard Biener wrote:
> > On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-patches
> > wrote:
> >>
> >> Hello All:
> >>
> >>
> >> This patch eliminates unnecessary zero extension instruction from p
Hello Richard:
On 16/03/23 1:10 pm, Richard Biener wrote:
> On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-patches
> wrote:
>>
>> Hello All:
>>
>>
>> This patch eliminates unnecessary zero extension instruction from power
>> generated assembly.
>> Bootstrapped and regtested on powerpc64-li
On Thu, Mar 16, 2023 at 6:35 AM HAO CHEN GUI via Gcc-patches
wrote:
>
> Hi,
> Currently, rs6000 directly expands to 2 insns if an integer constant is the
> second operand and it needs two insns. For example, addi/addis and ori/oris.
> It may not benefit when the constant is used for more than 2
On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-patches
wrote:
>
> Hello All:
>
>
> This patch eliminates unnecessary zero extension instruction from power
> generated assembly.
> Bootstrapped and regtested on powerpc64-linux-gnu.
What makes this so special that we cannot deal with it from
On Wed, 15 Mar 2023, Alexandre Oliva wrote:
>
> This test is similar to pr103116-1.c, but instead of writing to
> 4*COUNT elements of x, it writes to 8*COUNT elements, but the
> definition of x seems to have been adjusted along with the loop. Fix
> the array size so that it doesn't scribble over
70 matches
Mail list logo
