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 replies to
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959
--- Comment #5 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:24a7980d0f48671ea13da18c9162a43420b5af58
commit r13-4872-g24a7980d0f48671ea13da18c9162a43420b5af58
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
--- Comment #8 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:24a7980d0f48671ea13da18c9162a43420b5af58
commit r13-4872-g24a7980d0f48671ea13da18c9162a43420b5af58
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207
Bug ID: 108207
Summary: ICE in testcase g++.dg/other/ptrmem8.C on mingw
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208
--- Comment #1 from Sam James ---
Ah, based on https://bugzilla.redhat.com/show_bug.cgi?id=427700#c3 &
https://bugzilla.redhat.com/show_bug.cgi?id=427700#c5, maybe the source really
does just need splitting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #2 from Martin Liška ---
@Marek: PING
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 -
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
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208
Bug ID: 108208
Summary: Build failure on large LLVM source files on PPC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206
Martin Liška changed:
What|Removed |Added
Summary|ICE: tree check: expected |ICE: tree check: expected
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207
--- Comment #1 from nightstrike ---
Ah, Andrew, before you beat me to it... this doesn't ICE if you pass
-fno-ms-extensions, and it does ICE on Linux if you pass -fms-extensions
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
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.
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107548
--- Comment #1 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:0b2c1369d035e92847cca81fd9f7b4e9ab9da710
commit r13-4873-g0b2c1369d035e92847cca81fd9f7b4e9ab9da710
Author: Roger Sayle
Date: Fri
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:
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
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:
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
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.
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=108213
Bug ID: 108213
Summary: [[noreturn]] cannot be used after static keyword
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
> 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=108214
Bug ID: 108214
Summary: writinng bitset to stringstream fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
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!
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=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=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=108213
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
Andrew Pinski changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
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:
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
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:
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
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
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
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
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=108068
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
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.
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++
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:
>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
> 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=108211
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
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 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
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 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
> >
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:
> > > > >
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
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 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 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):
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,
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
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
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
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=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:
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=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:
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
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
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=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
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, 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, 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
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.
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=108102
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
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
--- 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
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Component|rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
> 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
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=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:
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=108216
--- Comment #1 from Arthur O'Dwyer ---
Possibly tangentially related: #70644, #81051
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
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 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
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
1 - 100 of 125 matches
Mail list logo
