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
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
NightStrike wrote:
[...]
Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja. So I'll keep those
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #6 from Egor Pugin ---
Same issue.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
Jonathan Wakely changed:
What|Removed |Added
Summary| pretty printers|[13 Regression] pretty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211
--- Comment #1 from Jonathan Wakely ---
The obvious solution is to try locate_zone(dir/filename) and if that fails try
locate_zone(filename).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
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
Snapshot gcc-11-20221223 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20221223/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6a95f0e0a06d78d94138d4c3dd64d41591197281
commit r13-4880-g6a95f0e0a06d78d94138d4c3dd64d41591197281
Author: Harald Anlauf
Date:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #11 from James McKelvey ---
(In reply to Christophe Lyon from comment #10)
> Can you try to revert my patches:
> f0d3b6e384a68f8b58bc750f240a15cad92600cd
> ccb9c7b129206209cfc315ab1a0432b5f517bdd9
> and remove your patch at comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #5 from Andrew Pinski ---
(In reply to Stefan Schulze Frielinghaus from comment #4)
> and the current working directory was most likely /devel/gcc/build/gcc.
> Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #5 from Andrew Pinski ---
(In reply to Stefan Schulze Frielinghaus from comment #4)
> and the current working directory was most likely /devel/gcc/build/gcc.
> Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #4 from Stefan Schulze Frielinghaus
---
I was playing around with this and was wondering how can I actually execute the
stageN compiler? From the output of make I see two compilations for object
rust-hir-trait-resolve.o. Thus the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #4 from Stefan Schulze Frielinghaus
---
I was playing around with this and was wondering how can I actually execute the
stageN compiler? From the output of make I see two compilations for object
rust-hir-trait-resolve.o. Thus the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #11 from federico ---
Thank you.
I can confirm the patch works.
I thought that, while fixing the issue, removing the assert was not the best
solution as automatic arrays are not supposed to be static. My bad.
Happy holidays,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #3 from Thiago Macieira ---
In bug 70644, the pointer to Base was passed to Base's constructor, so the
conversion from the derived type to the virtual base Base happened clearly
before said base was constructed.
In this example
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #2 from Andrew Pinski ---
Right reading bug 70644, then this code might be undefined.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #1 from Arthur O'Dwyer ---
Possibly tangentially related: #70644, #81051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
Bug ID: 108216
Summary: Wrong offset for (already-constructed) virtual base
during construction of full object
Product: gcc
Version: 13.0
Status: UNCONFIRMED
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108215
Bug ID: 108215
Summary: Does not optimize trivial case with bit operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Component|rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #10 from Christophe Lyon ---
Can you try to revert my patches:
f0d3b6e384a68f8b58bc750f240a15cad92600cd
ccb9c7b129206209cfc315ab1a0432b5f517bdd9
and remove your patch at comment #5 ?
You should still see the problem you reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209
--- Comment #1 from Alexander Monakov ---
Keeping notes as I go...
Duplicated checks for 'op0' in lower_for are duplicated.
> 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
>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877
Roger Sayle changed:
What|Removed |Added
Target Milestone|12.3|13.0
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214
Bug ID: 108214
Summary: writinng bitset to stringstream fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
Patrick Palka changed:
What|Removed |Added
Known to work||13.0
Summary|[12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cf59c8983ef6590f0d69014f8dc8778b5b7691c6
commit r13-4879-gcf59c8983ef6590f0d69014f8dc8778b5b7691c6
Author: Patrick Palka
Date:
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:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
Andrew Pinski changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108213
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107993
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Liška
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108213
Bug ID: 108213
Summary: [[noreturn]] cannot be used after static keyword
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #3 from Martin Liška ---
Created attachment 54153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54153=edit
pr108085.c.216t.uncprop1.dot.svg
So no, it's a real issue where we optimize out .ASAN_CHECK (6, , 4, 8); in
the exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fd1b0aefda5b65f3f841ca6e61ccea6a72daa060
commit r13-4877-gfd1b0aefda5b65f3f841ca6e61ccea6a72daa060
Author: Jakub Jelinek
Date:
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
Bug ID: 108212
Summary: pretty printers don't work with Python 2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108211
Bug ID: 108211
Summary: std::chrono::current_zone() fails if zone only has one
component
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bd1fc4a219d8c0fad0ec41002e895b49e384c1c2
commit r13-4876-gbd1fc4a219d8c0fad0ec41002e895b49e384c1c2
Author: Patrick Palka
Date:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #15 from Martin Liška ---
@Richi: Please send the patch for switch conversion in the next stage 1.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203
--- Comment #2 from LIU Hao ---
(In reply to nightstrike from comment #0)
> Bug report that came from it:
> https://sourceforge.net/p/mingw-w64/bugs/292/
>
I think this should be no longer the case. Two years ago I submitted a patch
that made
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
Bug ID: 108210
Summary: error: 'mutex' does not name a type; did you mean
'minutes'? for x86_64-w64-mingw32 target with win32
thread model
Product: gcc
Version:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209
Bug ID: 108209
Summary: goof in genmatch.cc:commutative_op
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
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
Le 23/12/2022 à 11:36, NightStrike a écrit :
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
NightStrike wrote:
[...]
Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja. So
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:
1 - 100 of 125 matches
Mail list logo
