On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful.
That would be awesome. It's not like this this is burning or anything
and one of the
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
--- Comment #4 from Julien Bernard ---
(In reply to Jonathan Wakely from comment #3)
I wasn't sure how to describe this issue, so my last sentence was probably
incorrect.
> I suspect this is covered by [temp.point] p7:
>
> "If two different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111448
Levi Zim changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #6 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Yi from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > _5 = var_0_16(D) + var_6_18(D);
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #3 from Andrew Pinski ---
Oh 0 is from:
/* Build the gcov info var, this is referred to in its own
initializer. */
gcov_info_var = build_decl (BUILTINS_LOCATION,
VAR_DECL, NULL_TREE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #2 from Andrew Pinski ---
Hmm:
```
static void
build_gcov_info_var_registration (tree gcov_info_type)
{
tree var = build_decl (BUILTINS_LOCATION,
VAR_DECL, NULL_TREE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #1 from Amyspark ---
Created attachment 56014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56014=edit
Full compiler version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
Bug ID: 111635
Summary: Objects built with -flto cannot be linked with Xcode
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Wed, Sep 27, 2023 at 03:13:35PM +0100, Jonathan Wakely wrote:
> On Sat, 23 Sept 2023 at 08:30, Nathaniel Shead via Libstdc++
> wrote:
> >
> > On Sat, Sep 23, 2023 at 07:40:48AM +0100, Jonathan Wakely wrote:
> > > On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
> > >
Snapshot gcc-11-20230928 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230928/
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=111466
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns implicitly sign-extend too.)
Existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
--- Comment #2 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #1)
> #1. REE reports failure as "missing definition(s)".
>
> This is because function args don't have an explicit def, they are just
> there.
>
> Cannot eliminate
On Thu, 28 Sept 2023, 21:38 Tom Tromey, wrote:
> Jonathan> I've pushed the changes I wanted to make, so you'll have to
> rebase
> Jonathan> your patches now, sorry.
>
> No problem. I rebased & re-tested them.
> I can send a v2 if you want to double-check (only this large patch
> required any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110951
Edwin Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Jonathan> I've pushed the changes I wanted to make, so you'll have to rebase
Jonathan> your patches now, sorry.
No problem. I rebased & re-tested them.
I can send a v2 if you want to double-check (only this large patch
required any changes), or just go ahead. Let me know.
I may not be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111621
--- Comment #1 from Andrew Pinski ---
Created attachment 56012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56012=edit
testcase (-march=rv64imafdcv -mabi=lp64d -O3)
Please next time attach the testcase (or put it inline) and not just a
On Thu, 28 Sept 2023 at 18:50, Tom Tromey via Libstdc++
wrote:
>
> GDB 14 will add a new ValuePrinter tag class that will be used to
> signal that pretty-printers will agree to the "extension protocol" --
> essentially that they will follow some simple namespace rules, so that
> GDB can add new
Tested x86_64-linux (GDB 13.2, Python 3.11). Pushed to trunk.
-- >8 --
This copies the is_specialization_of function from printers.py (with
slight modification for versioned namespace handling) and reuses it in
xmethods.py to replace repetitive re.match calls in every class.
This fixes the
Tested x86_64-linux (GDB 13.2, Python 3.11). Pushed to trunk.
-- >8 --
Some of these changes were suggested by autopep8's --aggressive
option, others are for readability.
Break long lines by splitting strings across multiple lines, or
introducing local variables to hold results.
Use raw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111623
--- Comment #1 from Andrew Pinski ---
Most likely this will be closed as fixed for GCC 12.
There are some riscv atomic issues which were fixed post GCC 13 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
Tested x86_64-linux (GDB 13.2, Python 3.11). Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Format docstrings according
to PEP 257.
* python/libstdcxx/v6/xmethods.py: Likewise.
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 177
On Thu, Sep 28, 2023 at 4:00 PM Toon Moene wrote:
> On 9/28/23 21:26, Jakub Jelinek wrote:
>
> > It is worse than that, usually the LTO format changes e.g. any time any
> > option or parameter is added on a release branch (several times a year)
> and
> > at other times as well.
> > Though,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505
--- Comment #5 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #4)
> Is it a ggc_common_finalize() bug in assuming that `base` does not point to
> the bbeginning of a struct?
> Or a `gt_ggc_r_gt_cp_tree_h` bug that it
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
Andrew Pinski changed:
What|Removed |Added
CC||lis8215 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111626
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
From: Sergei Trofimovich
There are 3 GC root tables:
gt_ggc_rtab
gt_ggc_deletable_rtab
gt_pch_scalar_rtab
`deletable` and `scalar` tables are both simple: each element always
contains a pointer to the beginning of the object and it's size is the
full object.
`rtab` is different: it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111626
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end
This patch fixes the handling of surrogate code points in all standard
facets for transcoding Unicode that are based on std::codecvt. Surrogate
code points should always be treated as error. On the other hand
surrogate code units can only appear in UTF-16 and only when they come
in a proper pair.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111630
--- Comment #3 from Andrew Pinski ---
Note the extra stuff comes from SCCP when it is trying to reduce the
depedencies on the IV from the loop.
On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> >
> > I didn't attend the Cauldron (but that discussion would have been
> >
On Wed, 2023-09-27 at 22:20 +0200, Benjamin Priour wrote:
> Hi everyone,
>
> I'm in my final MSc year and figured after this weekend's Q
> that I could replicate David's workshop on a smaller scale within my
> university.
>
> Would that be doable/acceptable ?
That sounds like a great idea.
>
Jonathan> I already have a patch to use r'...' for these, so we only
Jonathan> need the single backslash.
Yeah, probably nicer.
Jonathan> So please don't commit this one, I think it will be
Jonathan> unnecessary in a couple of hours.
No problem, I'll drop it when I rebase on top of your
On 9/28/23 11:26, Jason Merrill wrote:
On 9/28/23 05:55, Richard Sandiford wrote:
poly_int was written before the switch to C++11 and so couldn't
use explicit default constructors. This led to an awkward split
between poly_int_pod and poly_int. poly_int simply inherited from
poly_int_pod
On 9/28/23 07:33, Thomas Koenig wrote:
Hi Toon,
[ I wrote: ]
The full question of "lto-ing" run time libraries is more complicated
than just "whether it works" as those who attended the BoF will recall.
I didn't attend the Cauldron (but that discussion would have been
very interesting).
On Thu, 28 Sept 2023, 18:55 Tom Tromey via Libstdc++,
wrote:
> This removes the std_ratio_t_tuple function from the Python
> pretty-printer code. It is not used. Apparently the relevant parts
> were moved to StdChronoDurationPrinter._ratio at some point in the
> past.
>
I think I added it at
rtl-checking-testsuite/build-rv64gcv/../gcc/configure
>--target=riscv64-unknown-linux-gnu --prefix=/
>// Thread model: posix
>// Supported LTO compression algorithms: zlib zstd
>// gcc version 14.0.0 20230928 (experimental) (g8552dcd8e44)
>//
>// during RTL pass: expand
>// ../gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111634
Bug ID: 111634
Summary: RISC-V vector: ICE RTL check: expected code 'reg',
have 'lo_sum' in rhs_regno, at rtl.h:1934
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
On Thu, 28 Sept 2023, 18:50 Tom Tromey via Libstdc++,
wrote:
> flake8 pointed out some unused imports.
>
OK, thanks.
> libstdc++-v3/ChangeLog:
>
> * python/libstdcxx/v6/printers.py: Don't import 'os'.
> * python/libstdcxx/v6/__init__.py: Don't import 'gdb'.
> ---
>
On Thu, 28 Sept 2023, 18:50 Tom Tromey via Libstdc++,
wrote:
> flake8 pointed out some unused local variables in the libstdc++
> pretty-printers. This removes them.
>
OK, thanks.
> libstdc++-v3/ChangeLog:
>
> * python/libstdcxx/v6/printers.py
>
On Thu, 28 Sept 2023, 18:54 Tom Tromey via Libstdc++,
wrote:
> flake8 warns about code like
>
> not something in "whatever"
>
> Ordinarily in Python this should be written as:
>
> something not in "whatever"
>
> This patch makes this change.
>
OK, thanks.
> libstdc++-v3/ChangeLog:
>
On Thu, 28 Sept 2023, 18:50 Tom Tromey via Libstdc++,
wrote:
> flake8 pointed out that some regexes in the pretty-printers are
> missing a backslash. This patch fixes these.
>
I already have a patch to use r'...' for these, so we only need the single
backslash.
I'm also refactoring all those
On Thu, 28 Sept 2023, 18:48 Tom Tromey via Libstdc++,
wrote:
> This changes the libstdc++ test suite to arrange for gdb to show the
> full Python stack if any sort of Python exception occurs. This makes
> debugging the printers a little simpler.
>
Oh I wish I'd known about this sooner.
OK for
On Thu, 28 Sept 2023, 18:37 Tom Tromey, wrote:
> Jonathan> The changes made by black seem reasonable, though I prefer it
> Jonathan> with -S to disable string-normalization. It also needs an
> Jonathan> option to use 79 as the maximum line length.
>
> I've got some patches I'm about to send.
>
>
Hi Andre,
The patch looks fine to me. Since you mention it in the comment, is it
worth declaring the derived type 'foo' in a module and giving it a
final routine?
Thanks for the patch.
Paul
On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran
wrote:
>
> Hi all,
>
> attached patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568
--- Comment #1 from 康桓瑋 ---
bind_front also seems to missing Mandates:
https://godbolt.org/z/8WPxc44h6
#include
struct OnlyMovableFun {
OnlyMovableFun() = default;
OnlyMovableFun(const OnlyMovableFun&) = delete;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Thomas Koenig changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
GDB 14 will add a new ValuePrinter tag class that will be used to
signal that pretty-printers will agree to the "extension protocol" --
essentially that they will follow some simple namespace rules, so that
GDB can add new methods over time.
A couple new methods have already been added to GDB, to
flake8 warns about code like
not something in "whatever"
Ordinarily in Python this should be written as:
something not in "whatever"
This patch makes this change.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (Printer.add_version)
flake8 pointed out some unused local variables in the libstdc++
pretty-printers. This removes them.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpOptionalPrinter.__init__, lookup_node_type):
Remove unused variables.
---
flake8 pointed out that some regexes in the pretty-printers are
missing a backslash. This patch fixes these.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpAnyPrinter.__init__, StdExpOptionalPrinter.__init__):
Add missing backslash.
*
This removes the std_ratio_t_tuple function from the Python
pretty-printer code. It is not used. Apparently the relevant parts
were moved to StdChronoDurationPrinter._ratio at some point in the
past.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (std_ratio_t_tuple):
flake8 pointed out some unused imports.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Don't import 'os'.
* python/libstdcxx/v6/__init__.py: Don't import 'gdb'.
---
libstdc++-v3/python/libstdcxx/v6/__init__.py | 2 --
libstdc++-v3/python/libstdcxx/v6/printers.py | 1
GDB 14 will include a gdb.ValuePrinter tag class that can be used by
pretty-printers to signal they will accept any extensions that GDB
happens to make over time.
This series started as an attempt to change the libstdc++ printers to
support this. This just involves renaming a bunch of
This changes the libstdc++ test suite to arrange for gdb to show the
full Python stack if any sort of Python exception occurs. This makes
debugging the printers a little simpler.
libstdc++-v3/ChangeLog:
* testsuite/lib/gdb-test.exp (gdb-test): Enable Python
stack traces from
Jonathan> The changes made by black seem reasonable, though I prefer it
Jonathan> with -S to disable string-normalization. It also needs an
Jonathan> option to use 79 as the maximum line length.
I've got some patches I'm about to send.
I made a pyproject.toml to auto-configure black (and isort),
On 9/28/23 05:55, Richard Sandiford wrote:
poly_int was written before the switch to C++11 and so couldn't
use explicit default constructors. This led to an awkward split
between poly_int_pod and poly_int. poly_int simply inherited from
poly_int_pod and added constructors, with the
On 28/09/2023 18:18, Jonathan Wakely wrote:
On Wed, 27 Sept 2023 at 05:44, François Dumont wrote:
Still no chance to get feedback from TC ? Maybe I can commit the below
then ?
I've heard back from Tim now. Please use "Tim Song
" as the author.
You can change the commit again using git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #12 from CVS Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:2c1e3544a94c5d7354fad031e1f9731c3ce3af25
commit r14-4313-g2c1e3544a94c5d7354fad031e1f9731c3ce3af25
Author: Tim Song
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111633
Bug ID: 111633
Summary: __restrict on a member function is permitted in an
inconsistent location relative to ref-qualifiers
Product: gcc
Version: 14.0
Status:
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as , , etc, causes many compilation
errors, similar to:
In file included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #1 from Dimitry Andric ---
Created attachment 56010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56010=edit
Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Bug ID: 111632
Summary: gcc's C++ components fail to compile against recent
libc++ headers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
On Wed, 27 Sept 2023 at 05:44, François Dumont wrote:
>
> Still no chance to get feedback from TC ? Maybe I can commit the below
> then ?
I've heard back from Tim now. Please use "Tim Song
" as the author.
You can change the commit again using git commit --amend --author "Tim
Song "
OK for
I've got a lot of complaints about my recent patch to improve equiv cost
calculation. So I am reverting the patch.
commit 8552dcd8e4448c02fe230662093756b75dd94399
Author: Vladimir N. Makarov
Date: Thu Sep 28 11:53:51 2023 -0400
Revert "[RA]: Improve cost calculation of pseudos with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111533
Patrick O'Neill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 31/08/2023 07:39, Richard Biener wrote:
On Wed, Aug 30, 2023 at 5:02 PM Andre Vieira (lists)
wrote:
On 30/08/2023 14:01, Richard Biener wrote:
On Wed, Aug 30, 2023 at 11:15 AM Andre Vieira (lists) via Gcc-patches
wrote:
This patch adds a machine_mode parameter to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111630
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111630
--- Comment #1 from Andrew Pinski ---
Created attachment 56009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56009=edit
testcase
Please next time attach or inline the source so we don't need to depend on
external web sites.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
--- Comment #2 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:d8b56c95782a79ec40932ca88d00fd9f2ee2
commit r14-4311-gd8b56c95782a79ec40932ca88d00fd9f2ee2
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111631
--- Comment #2 from Andrew Pinski ---
ldist produces:
b_25 = (long int) j_23;
d_26 = h;
_8 = (sizetype) d_26;
_38 = (char *) b_25;
__builtin_memset (_38, 0, _8);
and also we have:
[local count: 13370358]:
if (j_23 != 0)
goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111631
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111583
--- Comment #2 from Andrew Pinski ---
*** Bug 111631 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111631
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|Wrong code at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505
--- Comment #4 from Sergei Trofimovich ---
In https://gcc.gnu.org/PR111629#c0 profiled bootstrap fales for a similar
reason.
There ggc_common_finalize() memset()s unexpected memory location
#1 0x01933651 in ggc_common_finalize () at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
--- Comment #3 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> Created attachment 56006 [details]
> preprocessed riscv insn-opinit.cc
I get
i.ii:2203:11: fatal error: definition of ‘class std::initializer_list<_E>’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281
--- Comment #6 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #1)
> Given the amount of code in the wild that assumes 1 << 31 etc. work, I think
> it would be a bad idea to try to optimize this for C99, especially when it
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:88d8829e4f435bfc844db5a9df730e20faf7c2c7
commit r14-4310-g88d8829e4f435bfc844db5a9df730e20faf7c2c7
Author: Pan Li
Date: Thu Sep 28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #8 from Franz Sirl ---
The proposed patch on top of r14-4307 fixes the profiled bootstrap here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505
Andrew Pinski changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111629
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-28 22:15
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Support {U}INT64 to FP16 auto-vectorization
From: Pan Li
Update in v2:
* Add math trap check.
* Adjust some test cases.
From: Pan Li
Update in v2:
* Add math trap check.
* Adjust some test cases.
Original logs:
This patch would like to support the auto-vectorization from
the INT64 to FP16. We take below steps for the conversion.
* INT64 to FP32.
* FP32 to FP16.
Given sample code as below:
void
test_func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111629
--- Comment #1 from Andrew Pinski ---
There is a dup of this where valgrind complains.
On Thu, Sep 28, 2023 at 10:55:46AM +0100, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu & x86_64-linux-gnu. Also tested with
> Jakub's vec.h patch with the static_asserts uncommented; there were
> no errors from poly_int-related stuff. OK to install?
LGTM (mostly as the general idea,
Hi!
On Tue, Aug 29, 2023 at 05:09:52PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Aug 29, 2023 at 11:42:48AM +0100, Richard Sandiford wrote:
> > > I'll note tree-ssa-loop-niter.cc also uses GMP in some cases, widest_int
> > > is really trying to be poor-mans GMP by limiting the maximum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111624
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111631
Bug ID: 111631
Summary: Wrong code at -Os on x86_64-linux-gnu since
r14-3217-g4d6132e5932
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
No problem!
I'll send a follow up with the requested changes.
Thanks for the input!
Manos.
On Thu, Sep 28, 2023 at 4:42 PM Richard Sandiford
wrote:
> Manos Anagnostakis writes:
> > Hey Richard,
> >
> > Thanks for taking the time to review this, but it has been commited since
> > yesterday
I've pushed the following patch. The explanation is in commit message.
The patch was successfully bootstrapped on x86-64.
commit 0c8ecbcd3cf7d7187d2017ad02b663a57123b417
Author: Vladimir N. Makarov
Date: Thu Sep 28 09:41:18 2023 -0400
[RA]: Add flag for checking IRA in progress
Manos Anagnostakis writes:
> Hey Richard,
>
> Thanks for taking the time to review this, but it has been commited since
> yesterday after getting reviewed by Kyrill and Tamar.
>
> Discussions:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631285.html
>
Sure, I will attend to this.
Manos.
On Thu, Sep 28, 2023 at 4:37 PM Philipp Tomsich
wrote:
> Manos,
>
> Please submit a follow-on patch implementing the requested
> improvements of the code structure (as this reduces the maintenance
> burden).
>
> Thanks,
> Philipp.
>
>
> On Thu, 28 Sept 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111630
Bug ID: 111630
Summary: Optimizing for size compiles additions to several
instructions
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
HAO CHEN GUI writes:
> Kewen and Richard,
> Thanks for your comments. Please let me clarify it.
>
> 在 2023/9/27 19:10, Richard Sandiford 写道:
>> Yeah, I agree there doesn't seem to be a good reason to exclude vectors.
>> Sorry to dive straight into details, but maybe we should have something
>>
Manos,
Please submit a follow-on patch implementing the requested
improvements of the code structure (as this reduces the maintenance
burden).
Thanks,
Philipp.
On Thu, 28 Sept 2023 at 15:33, Manos Anagnostakis
wrote:
>
> Hey Richard,
>
> Thanks for taking the time to review this, but it has
1 - 100 of 185 matches
Mail list logo
