On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
On 2022-12-23 23:59, Jonathan Yong wrote:
Done, pushed to master branch. Thanks Eric.
thank you Jonathan!
On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
wrote:
>
> On 12/22/22 12:28, i.nix...@autistici.org wrote:
> > On 2022-12-22 12:21, Jonathan Yong wrote:
> >
> > hello,
> >
> >> On 12/16/22 19:20, Eric Botcazou wrote:
> The libgcc parts look reasonable to me, but I can't
From: Ju-Zhe Zhong
This patch is to fix issue of visiting non-existing block of CFG.
Since blocks index of CFG in GCC are not always contiguous, we will potentially
visit a gap block which is no existing in the current CFG.
This patch can avoid visiting non existing block in CFG.
I noticed
On Linux/x86_64,
0b2c1369d035e92847cca81fd9f7b4e9ab9da710 is the first bad commit
commit 0b2c1369d035e92847cca81fd9f7b4e9ab9da710
Author: Roger Sayle
Date: Fri Dec 23 09:56:30 2022 +
PR target/107548: Handle vec_select in STV on x86.
caused
FAIL: gcc.target/i386/pr107548-1.c
Hi Ian (and Andreas),
On Wed, 14 Dec 2022, Lorenzo Salvadore wrote:
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605685.html
>
> I would like to remind that Gerald Pfeifer already volunteered to commit
> this patch when it is approved. However the patch has not been approved
On 12/22/22 12:28, i.nix...@autistici.org wrote:
On 2022-12-22 12:21, Jonathan Yong wrote:
hello,
On 12/16/22 19:20, Eric Botcazou wrote:
The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a
On Fri, 23 Dec 2022, 17:06 Iain Sandoe via Libstdc++,
wrote:
> This is a patch for comment on the approach - tested on x86_64-darwi21
> thoughts?
> Iain
>
> --- 8< ---
>
> Testing on Darwin revealed that the GLIBCXX_ZONEINFO_DIR was not doing
> quite
> the right thing (we ended up with
On 12/23/22 6:08 AM, Thomas Schwinge wrote:
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
For example, for Fortran code like:
write (*,*) "Hello world"
..., 'gfortran' creates:
struct __st_parameter_dt
On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote:
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array element
Hi!
On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote:
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option powerpc64 in rs6000_handle_option.
>
> Segher pointed out this difference should be taken as
> a bug
> On Dec 23, 2022, at 2:36 PM, Alexander Monakov wrote:
>
>
>
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>
>> Then, sched2 still can move insn across calls?
>> So does sched2 have the same issue of incorrectly moving the insn across a
>> call which has unknown control flow?
>
> I think
On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote:
> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool
> > :
> > There are at least six very different kinds of subreg:
> >
> > 0) Lvalue subregs. Most archs have no use for it, and it can be
> > expressed much more clearly and
On Fri, 23 Dec 2022, Qing Zhao wrote:
> Then, sched2 still can move insn across calls?
> So does sched2 have the same issue of incorrectly moving the insn across a
> call which has unknown control flow?
I think problems are unlikely because register allocator assigns pseudos that
cross
Then, sched2 still can move insn across calls?
So does sched2 have the same issue of incorrectly moving the insn across a
call which has unknown control flow?
Qing
> On Dec 23, 2022, at 12:31 PM, Alexander Monakov wrote:
>
>
> On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
>
>>> (scheduling
> Am 23.12.2022 um 17:55 schrieb Segher Boessenkool
> :
>
> On Fri, Dec 23, 2022 at 05:20:09PM +0100, Richard Biener wrote:
Am 23.12.2022 um 15:48 schrieb Segher Boessenkool
:
>>> None of this belongs in generic code at all imo. At expand time it
>>> should be expanded to
> On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
>
>> > (scheduling across calls in sched2 is somewhat dubious as well, but
>> > it doesn't risk register pressure issues, and on VLIW CPUs it at least
>> > can result in better VLIW packing)
>>
>> Does sched2 actually schedule across calls? All
On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
> > (scheduling across calls in sched2 is somewhat dubious as well, but
> > it doesn't risk register pressure issues, and on VLIW CPUs it at least
> > can result in better VLIW packing)
>
> Does sched2 actually schedule across calls? All the
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>> >> I am a little confused, you mean pre-RA scheduler does not look at the
>> >> data flow
>> >> information at all when scheduling insns across calls currently?
>> >
>> > I think it does not inspect liveness info, and may extend lifetime of a
>> >
On Fri, Dec 23, 2022 at 5:46 PM Roger Sayle wrote:
>
>
> This patch tweaks the x86 backend to use the movss and movsd instructions
> to perform some vector permutations on integer vectors (V4SI and V2DI) in
> the same way they are used for floating point vectors (V4SF and V2DF).
>
> As a
This is a patch for comment on the approach - tested on x86_64-darwi21
thoughts?
Iain
--- 8< ---
Testing on Darwin revealed that the GLIBCXX_ZONEINFO_DIR was not doing quite
the right thing (we ended up with ${withval} in the config.h file).
This patch proposes revising the behaviour of
On Fri, Dec 23, 2022 at 05:20:09PM +0100, Richard Biener wrote:
> > Am 23.12.2022 um 15:48 schrieb Segher Boessenkool
> > :
> > None of this belongs in generic code at all imo. At expand time it
> > should be expanded to something that works and can be optimised well,
> > so not anything with
This patch tweaks the x86 backend to use the movss and movsd instructions
to perform some vector permutations on integer vectors (V4SI and V2DI) in
the same way they are used for floating point vectors (V4SF and V2DF).
As a motivating example, consider:
typedef unsigned int v4si
> Am 23.12.2022 um 15:48 schrieb Segher Boessenkool
> :
>
> Hi!
>
>> On Fri, Dec 23, 2022 at 08:36:36PM +0800, Jiufu Guo wrote:
>> It seems some limitations there. e.g. 1. "subreg:DF on DI register"
>> may not work well on pseudo,
>
> It is perfectly normal:
> A hard register may be
Am 17.12.22 um 22:21 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array
On 12/23/22 10:48, Patrick Palka wrote:
On Thu, 22 Dec 2022, Patrick Palka wrote:
On Thu, 22 Dec 2022, Jason Merrill wrote:
On 12/22/22 16:41, Patrick Palka wrote:
On Thu, 22 Dec 2022, Jason Merrill wrote:
On 12/22/22 11:31, Patrick Palka wrote:
On Wed, 21 Dec 2022, Jason Merrill wrote:
On Thu, 22 Dec 2022, Patrick Palka wrote:
> On Thu, 22 Dec 2022, Jason Merrill wrote:
>
> > On 12/22/22 16:41, Patrick Palka wrote:
> > > On Thu, 22 Dec 2022, Jason Merrill wrote:
> > >
> > > > On 12/22/22 11:31, Patrick Palka wrote:
> > > > > On Wed, 21 Dec 2022, Jason Merrill wrote:
> > > > >
Hi.
We reach cond_expr and then we get an ICE in tree_int_cst_lt.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR tree-optimization/108137
gcc/ChangeLog:
* tree-ssa-strlen.cc (get_range_strlen_phi): Reject
Hi!
As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
if a floating point constant is zero and it shouldn't try to infer
equivalences from comparison against it if signed zeros are honored.
This doesn't work at all for decimal types, because real_zerop always
returns false for
On Fri, 23 Dec 2022, Qing Zhao wrote:
> >> I am a little confused, you mean pre-RA scheduler does not look at the
> >> data flow
> >> information at all when scheduling insns across calls currently?
> >
> > I think it does not inspect liveness info, and may extend lifetime of a
> > pseudo
> >
Thank you. Would you mind testing this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609045.html
to see whether the issue is fixed ?
Thanks
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2022-12-23 22:54
To: 钟居哲
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH]
On Dez 23 2022, 钟居哲 wrote:
> Would you mind telling me how you reproduce these errors ?
make bootstrap
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Thu, 15 Dec 2022 16:46:50 +
Julian Brown wrote:
> On Thu, 15 Dec 2022 14:54:58 +
> Julian Brown wrote:
>
> > On Wed, 7 Dec 2022 17:31:20 +0100
> > Tobias Burnus wrote:
> >
> > > Hi Julian,
> > >
> > > I think this patch is OK; however, at least for gimplify.cc Jakub
> > > needs
Hi!
On Fri, Dec 23, 2022 at 08:36:36PM +0800, Jiufu Guo wrote:
> It seems some limitations there. e.g. 1. "subreg:DF on DI register"
> may not work well on pseudo,
It is perfectly normal:
A hard register may be accessed in various modes throughout one
function, but each pseudo register is
> On Dec 23, 2022, at 2:33 AM, Alexander Monakov wrote:
>
>
> On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>>> I think scheduling across calls in the pre-RA scheduler is simply an
>>> oversight,
>>> we do not look at dataflow information and with 50% chance risk extending
>>> lifetime of a
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
> On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge
> wrote:
>> For example, for Fortran code like:
>>
>> write (*,*) "Hello world"
>>
>> ..., 'gfortran' creates:
>>
>> struct __st_parameter_dt dt_parm.0;
>>
>> try
I have committed the obvious as simple.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd
commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd
Author: Steve Kargl
Date: Thu Dec 22 20:38:57 2022 -0800
Remove not
A fix for another bootstrap error caused by yesterday's C++20 time zone
commit, for macOS this time.
I have only tested on x86_64-linux but Iain confirmed this works for his
darwin testers. Pushed to trunk.
-- >8 --
Mach-O requires weak symbols to have a definition, so add a default
Hi!
On 2022-12-23T14:35:16+0100, I wrote:
> On 2022-12-02T14:35:35+0100, I wrote:
>> On 2022-12-01T22:13:38+0100, I wrote:
>>> I'm working on support for global constructors/destructors with
>>> GCC/nvptx
>>
>> See "nvptx: Support global constructors/destructors via 'collect2'"
>> [posted before]
Hi!
On 2022-12-02T14:35:35+0100, I wrote:
> On 2022-12-01T22:13:38+0100, I wrote:
>> I'm working on support for global constructors/destructors with
>> GCC/nvptx
>
> See "nvptx: Support global constructors/destructors via 'collect2'"
> [posted before]
Building on that, attached is now the
HI,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Richard Biener writes:
>
>> On Thu, 22 Dec 2022, guojiufu wrote:
>>
>>> Hi,
>>>
>>> On 2022-12-21 15:30, Richard Biener wrote:
>>> > On Wed, 21 Dec 2022, Jiufu Guo wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> This patch is fixing an issue about
Hi, Andreas. Thank you for reporting this.
Even though I didn't reproduce this error, I have an idea to fix it:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609045.html
Would you mind testing this patch for me before merging it?
Thanks.
juzhe.zh...@rivai.ai
From: Andreas Schwab
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (change_insn): Remove pp_print.
(avl_info::avl_info): Add copy function.
(vector_insn_info::dump): Remove pp_print.
* config/riscv/riscv-vsetvl.h: Add copy function.
---
Hi,
Segher Boessenkool writes:
> On Thu, Dec 22, 2022 at 11:28:01AM +, Richard Biener wrote:
>> On Thu, 22 Dec 2022, Jiufu Guo wrote:
>> > To reduce risk, I'm just draft straightforward patches for
>> > special cases currently, Like:
>> >
Would you mind telling me how you reproduce these errors ?
I failed to reproduce this. Thanks
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2022-12-23 18:53
To: juzhe.zhong
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Support VSETVL PASS for RVV support
How has this been
This patch adds support for "declare mapper" directives (and the "mapper"
modifier on "map" clauses) for C. As for C++, arrays of custom-mapped
objects are not supported yet.
I've taken hints from the existing C support for "declare reduction"
directives: this works a little differently from C++
This is a new version of the patch to support OpenMP 5.0 "declare mapper"
functionality for C++. As with the previously-posted version, arrays
of structs whose elements would be mapped via a user-defined mapper
remain unsupported.
This version of the patch uses a magic VAR_DECL instead of a
This patch adds support for parsing general lvalues for OpenMP "map", "to"
and "from" clauses to the C front-end, similar to the previously-posted
patch for C++.
This version of the patch incorporates the patch to change uses of
TREE_LIST to the new OMP_ARRAY_SECTION tree code to represent OpenMP
This patch changes the mapping node arrangement used for array components
of derived types, e.g.:
type T
integer, pointer, dimension(:) :: arrptr
end type T
type(T) :: tvar
[...]
!$omp target map(tofrom: tvar%arrptr)
This will currently be mapped using three mapping nodes:
This patch implements "omp declare mapper" functionality for Fortran,
following the equivalent support for C and C++.
Fortran differs quite substantially from C and C++ in that "map"
clauses are naturally represented in the gfortran front-end's own
representation rather than as trees. Those are
This patch fixes some cases for OpenACC and OpenMP where map clauses were
being expanded (adding firstprivate_pointer, attach/detach nodes, and so
forth) unnecessarily, after the "OpenMP/OpenACC: Rework clause expansion
and nested struct handling" patch (approved but not yet committed):
Following from discussion in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570075.html
and:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608100.html
and also upstream OpenMP issue 342, this patch changes mapping for array
sections of pointer components on compute regions
This patch adds support for non-constant component offsets in "map"
clauses for OpenMP (and the equivalants for OpenACC), which are not able
to be sorted into order at compile time. Normally struct accesses in
such clauses are gathered together and sorted into increasing address
order after a
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc
Following on from here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608577.html
this is a complete patch series, rebased against mainline. The final
three patches are the revised C "lvalue"-parsing patches and C and Fortran
"declare mapper" support patches mentioned in that email.
How has this been tested?
In file included from ../../gcc/config/riscv/riscv-vsetvl.cc:89:
../../gcc/config/riscv/riscv-vsetvl.h: In member function
'riscv_vector::avl_info riscv_vector::vl_vtype_info::get_avl_info() const':
../../gcc/config/riscv/riscv-vsetvl.h:175:43: error:
> Alexander Monakov via Gcc-patches writes:
>> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>>
>>> The first instruction scheduler pass reorders instructions in the TRY
>>> block in a way `b=true' gets executed before the call to the function
>>> `f'. This optimization is
Alexander Monakov via Gcc-patches writes:
> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>
>> The first instruction scheduler pass reorders instructions in the TRY
>> block in a way `b=true' gets executed before the call to the function
>> `f'. This optimization is wrong, because
---
htdocs/index.html | 24
htdocs/news.html | 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index 2ddee6f6..2ab65a95 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -92,30
This patch adds an Atom feed for GCC news, which can then be easily
aggregated in other sites, such as the GNU planet
(https://planet.gnu.org).
The feed lives in a file news.xml, and this patch initializes it with
the latest entry in News as an example.
---
htdocs/index.html | 9 -
On Fri, 23 Dec 2022 at 09:29, Jonathan Wakely wrote:
>
> On Fri, 23 Dec 2022 at 02:15, Hans-Peter Nilsson via Libstdc++
> wrote:
> >
> > > From: Jonathan Wakely via Gcc-patches
> > > Date: Fri, 23 Dec 2022 00:37:04 +0100
> >
> > > This is the largest missing piece of C++20 support. Only the
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This assertion fails for cris-elf where sizeof(datetime) is only 7, due
to lower alignment requirements. The assertion was used while I was
writing the code to check that the objects were as compact as I wanted,
but it doesn't need to be kept now.
This patch adds an entry to the News section in index.html, announcing
the availability of a nightly build of bpf-unknown-none-gcc.
---
htdocs/index.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/index.html b/htdocs/index.html
index 655b7373..e91fadf1 100644
---
On Fri, 23 Dec 2022 at 02:15, Hans-Peter Nilsson via Libstdc++
wrote:
>
> > From: Jonathan Wakely via Gcc-patches
> > Date: Fri, 23 Dec 2022 00:37:04 +0100
>
> > This is the largest missing piece of C++20 support. Only the cxx11 ABI
> > is supported, due to the use of std::string in the API for
64 matches
Mail list logo
