https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #2 from Xi Ruoyao ---
I applied the LoongArch port patch (upstream PR 678, config.guess and
config.sub changes stripped and Makefile.am conflict resolved manually) and use
autogen.sh to regenerate the build system. But libgo build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109003
Bug ID: 109003
Summary: memory leak in module loading (mio_formal_arglist)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #9 from Jonathan Wakely ---
You can skip things not relevant to this issue by configuring with:
--disable-multilib --disable-bootstrap --enable-languages=c++,c
--disable-libcc1 --disable-libitm --disable-libvtv --disable-libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #8 from Andrew Pinski ---
Plus you can use --disable-bootstrap and maybe not rebuild llvm and just set
LD_LIBRARY_PATH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #7 from Andrew Pinski ---
(In reply to Tom Stellard from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Tom Stellard from comment #4)
> > > This test case was passing with older versions of LLVM/Clang +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #6 from Tom Stellard ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Tom Stellard from comment #4)
> > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> > so I bisected it down to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #14 from Martin Liška ---
(In reply to Marek Polacek from comment #13)
> I would really not like to do that, the false positives rate is pretty low.
You right! I noticed the warning for about 3 packages of 3300 we have in a
testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6010189923908501ca5b02bd1f4aee05d2283118
commit r13-6439-g6010189923908501ca5b02bd1f4aee05d2283118
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:33ca5c92dfa7e2f591a838bb768d9d6eea56793b
commit r13-6438-g33ca5c92dfa7e2f591a838bb768d9d6eea56793b
Author: Richard Biener
Date:
On Thu, Mar 2, 2023 at 2:28 PM Richard Biener wrote:
>
> The following puts a hard limit on the inherently quadratic STV chain
> discovery. Without a limit for the compiler.i testcase in PR26854
> we see at -O2
>
> machine dep reorg : 574.45 ( 53%)
>
> with release checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
--- Comment #2 from Akihiko Odaki ---
Oops. Replacing i++ with i = !i removes the undefined behavior while the bug
still remains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
--- Comment #1 from Andrew Pinski ---
Note there will be undefined behavior when i become INT_MAx.
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230302 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64'
/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/cc1
-quiet -v -iprefix
/home/alarm/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #12 from Surya Kumari Jangala ---
(In reply to Jens Seifert from comment #6)
> The left part of VSX registers overlaps with floating point registers, that
> is why no register xxpermdi is required and mfvsrd can access all (left)
>
Please don't use the same title for all the patches. This will puzzle
people running "git log" once they are committed.
And when you send 01-07, use "reply" instead of "new" so they will show
up in the correct location in a mail client. Or use git send-email
which is much eaiser to use.
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #7 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:1e4122f1159ace52c114c011013adce25172d77b
commit r13-6437-g1e4122f1159ace52c114c011013adce25172d77b
Author: Alexandre Oliva
This patch adds tests for autovectorization of integer add and subtract.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec: New directory
for autovectorization tests.
* gcc.target/riscv/rvv/autovec/loop-add-rv32.c: New
test to verify code generation of vector add on rv32.
This patch adds patterns that provide basic autovectorization support
for integer adds and subtracts.
gcc/ChangeLog:
* config/riscv/riscv.md (riscv_classify_vlmul_field):
New external declaration.
(riscv_vector_preferred_simd_mode): Include
vector-iterators.md.
*
This patch adds support for registering target hooks for basic
autovectorization support as well as basic tuning information for the
vector extension.
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE):
Add VECTOR_TUNE_INFO parameter and
*
This patch adds support for functions used in implementing various
portions of autovectorization support.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (riscv_classify_vlmul_field):
New function.
(riscv_vector_preferred_simd_mode): Ditto.
(get_mask_policy_no_pred): Ditto.
This patches adds two new files to support the vector cost model and
modifies the Makefile fragment to build the cost model c++ file. Due to
the large size this patch is provided as an attachment.
gcc/ChangeLog:
* gcc/config.gcc (riscv-vector-cost.o): New object file to build.
*
This patch adds foundational support by making two functions that handle
predication policies visibly globally.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (get_tail_policy_for_pred):
Remove static declaration to to make externally visible.
(get_mask_policy_for_pred):
This patch adds foundational support in the form of:
1. New predicates
2. New function prototypes
3. Exporting emit_vlmax_vsetvl to global scope
4. Add a new command line option -mriscv_vector_lmul
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_classify_vlmul_field):
New
This series of patches adds foundational support for RISC-V
autovectorization. These patches are based on the current upstream rvv
vector intrinsic support and is not a new implementation. Most of the
implementation consists of adding the new vector cost model, the
autovectorization patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109001
Bug ID: 109001
Summary: “no declaration matches” for complicated non-type
template parameters
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #1 from Xi Ruoyao ---
Merging libffi is a big change and not suitable for stage 3 IMO.
Can we can apply the LoongArch patch locally instead? It will not affect other
targets and even if does not work perfectly on LoongArch we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Fri, 2023-03-03 at 10:12 +0800, Yujie Yang wrote:
> However, "loongarch64" is defined to include the "fpu64" ISA module[1]
> (i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
> the above behavior you observed is expected.
Ah this make things much simpler and aligns with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Xi Ruoyao changed:
What|Removed |Added
Known to fail||12.2.0, 13.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Bug ID: 109000
Summary: LoongArch: "unmatched" -mabi and -mfpu setting can
break ABI silently
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #5 from Andrew Pinski ---
(In reply to Tom Stellard from comment #4)
> This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> so I bisected it down to this commit:
> https://github.com/llvm/llvm-project/commit/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #4 from Tom Stellard ---
This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, so I
bisected it down to this commit:
https://github.com/llvm/llvm-project/commit/6747fc07d1aa94e22622e278e5a02ba70675ac9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:c90e68bffa37edd655dd2f5d14bb7b213c9e2431
commit r10-11235-gc90e68bffa37edd655dd2f5d14bb7b213c9e2431
Author: Iain Buclaw
Got it. Thank you and very appreciate for your help and patient. Updated the
PATCH to below link.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613257.html
Pan
-Original Message-
From: Richard Sandiford
Sent: Friday, March 3, 2023 1:55 AM
To: Li, Pan2
Cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:fe6cd1ba23ecbce9c0206c08db182cb5164e3b7d
commit r11-10554-gfe6cd1ba23ecbce9c0206c08db182cb5164e3b7d
Author: Iain Buclaw
From: Pan Li
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:2583365912c8700abe1f4a23ed611acb80fac09d
commit r12-9212-g2583365912c8700abe1f4a23ed611acb80fac09d
Author: Iain Buclaw
On Fri, Mar 03, 2023 at 12:01:22AM +0800, Xi Ruoyao via Gcc-patches wrote:
> But then it causes "-mabi=lp64s -march=loongarch64" to generate code like:
>
> movgr2fr.d $fa0, $a0
> frecip.d $fa0, $fa0
> movfr2gr.d $a0, $fa0
>
> The problem here is "loongarch64" is never strictly defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #12 from David Edelsohn ---
We're working to add a Power10 system to the Compile Farm. The systems are at
OSUOSL, but Power10 doesn't have official KVM support so the interface to the
OpenStack management system is complicated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Bug ID: 108999
Summary: Maybe LRA produce inaccurate hardware register
occupancy information for subreg operand
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #11 from Rui Ueyama ---
I'll try to add a POWER10 support to mold using Qemu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:ce1cea3e22f58bbddde017f8a92e59bae8892339
commit r13-6432-gce1cea3e22f58bbddde017f8a92e59bae8892339
Author: Iain Buclaw
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:929c6b8cd12a3bd338a4c250274a9d86da5b2ea7
commit r13-6433-g929c6b8cd12a3bd338a4c250274a9d86da5b2ea7
Author: Iain Buclaw
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:33a7811896a6c8e6fa71e385dbdf5013d833a116
commit r13-6431-g33a7811896a6c8e6fa71e385dbdf5013d833a116
Author: Iain Buclaw
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:51af8a6401eea726d3498e6b2aba456b6af246d6
commit r13-6430-g51af8a6401eea726d3498e6b2aba456b6af246d6
Author: Iain Buclaw
Date: Mon
Hi,
When comparing two vectors, the type of vector was used as the result of
the condition result. This meant that for floating point comparisons,
each value would either be `0.0' or `-1.0' reinterpreted as an integer,
not the expected integral bitmask values `0' and `-1'.
Instead, use the
Hi,
This patch fixes an ICE in the D front-end when importing an immutable
struct. Const and immutable types are built as variants of the type
they are derived from, and TYPE_STUB_DECL is not set for these variants.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to
Hi,
Vector equality and comparisons are now accepted by the language
implementation, but identity wasn't. This patch implements it as an
extra integer comparison of the bit-casted bitmask.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.
Regards,
Iain.
Hi,
This patch adds the test for checking PR108167. The D front-end
implementation got fixed in upstream, add test to the gdc testsuite to
check we don't regress on it.
Regression tested on x86_64-linux-gnu/-m32, and committed to mainline.
Regards,
Iain.
---
PR d/108167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
--- Comment #4 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #3)
> For cond == 789
> if (cond_2(D) == 789)
> goto ; [20.24%]
> else
> goto ; [79.76%]
>
> For cond != 789
> if (cond_2(D) != 789)
> goto ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #3 from waffl3x ---
I made a mistake in my previous comment, the version on my system that fails is
12.2.1, sorry for any possible confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |13.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #1 from waffl3x ---
I ran it on my local system, just to get some line numbers, and I accidentally
ran it on an older version (12.1) and found that it has a similar result, I'm
posting the output of -v and the error of both here. As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
--- Comment #3 from Nikita Kniazev ---
For cond == 789
if (cond_2(D) == 789)
goto ; [20.24%]
else
goto ; [79.76%]
For cond != 789
if (cond_2(D) != 789)
goto ; [48.88%]
else
goto ; [51.12%]
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> on a structure with a C99 flexible array member being nested in
> another structure.
>
> "GCC extension accepts a structure containing an ISO C99 "flexible array
> member", or a union containing such a structure (possibly
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible size.
>
>
Ping
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> Hi, Joseph and Richard,
>
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #5 from Marek Polacek ---
I think p_c_e just needs to handle constexpr functors in templates. I'll poke
more tomorrow.
On 2/22/23 01:18, Florian Weimer via Gcc wrote:
Can we use the COMMON symbol __gnu_lto_slim to detect
-fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker
plugin)?
We currently build the distribution with -ffat-lto-objects, and I want
to switch away from that. Packages will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Bug ID: 108998
Summary: ICE in tsubst, at cp/pt.cc:16037
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
On Thu, Mar 02, 2023 at 01:43:30PM +, Jonathan Yong via Gcc-patches wrote:
> On 3/2/23 10:46, Richard Sandiford wrote:
> > > diff --git a/gcc/testsuite/gcc.dg/memchr-3.c
> > > b/gcc/testsuite/gcc.dg/memchr-3.c
> > > index c38d9cf3349..af1b26ef3ae 100644
> > > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991
commit r13-6428-g73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #16 from Andrew Pinski ---
(In reply to Costas Argyris from comment #15)
> Sounds like I am hitting a separate existing limitation that has nothing to
> do with this bug.
>
> Do we need a new bug report for that one then?
No one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #13 from Jakub Jelinek ---
Fixed now on the trunk. I'd wait a little bit with backports, though I think
the gmp-param.h change doesn't need backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16151
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26137
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18247
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16965
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa
commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6978df2c04df165eaa6aac9e17b6c770bed460e3
commit r13-6426-g6978df2c04df165eaa6aac9e17b6c770bed460e3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Nikita Kniazev from comment #6)
> > The duplication happens even if I make cond int and compare with any other
> > value
> >
> > void use(int *);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #7 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #6)
> The duplication happens even if I make cond int and compare with any other
> value
>
> void use(int *);
> void use2(int *);
>
> void foo(int * p, int cond)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
--- Comment #2 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #1)
> Is it about bool?
YES.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #6 from Nikita Kniazev ---
> Did you see this in real code or you just noticed this while looking at code
> generation?
If you mean do I have any benchmark - unfortunately no. I noticed it for a
while by poking different code to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
The PR complains that we do not handle UTF-8 in the suffix for a user-defined
literal, such as:
bool operator ""_π (unsigned long long);
In fact we don't handle any extended identifier characters there, whether
UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space after
the ""
On Fri, Mar 03, 2023 at 12:05:09AM +0100, Gerald Pfeifer wrote:
> On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> > +
> > +#include
>
> Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
> the above would be seen as a tag by the name of stdlib.h. ;-)
>
> I pushed the follow-up patch
On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> +
> +#include
Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
the above would be seen as a tag by the name of stdlib.h. ;-)
I pushed the follow-up patch below.
Gerald
commit 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5
Author: Gerald
On Linux/x86_64,
62a8d31ecc07041af4a81353c2d57d9845c4b771 is the first bad commit
commit 62a8d31ecc07041af4a81353c2d57d9845c4b771
Author: Jonathan Yong <10wa...@gmail.com>
Date: Mon Feb 27 10:02:32 2023 +
gcc.dg/memchr-3.c: Account for LLP64 warnings
caused
FAIL: gcc.dg/memchr-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote:
> I don't have push rights so if you could push it, it'd be super
> appreciated!
Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly
tweaking the subject line to add a "jit, testsuite: " prefix.
Thanks again for the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #5 from Andrew Pinski ---
Note I filed PR 108997 for what seems like the wrong heurstic for the
prediction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6b432c0f777ab9b8436fb07f71de6ea4d259b869
commit r13-6425-g6b432c0f777ab9b8436fb07f71de6ea4d259b869
Author: Guillaume Gomez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Bug ID: 108997
Summary: GCC prediction on bool comparisons seems wrong
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
This patch is second in importance after the first patch in the series. It is
needed to allow complex IBM 128-bit multiply/divide when long double is IEEE
128-bit.
| Date: Fri, 3 Feb 2023 00:53:05 -0500
| From: Michael Meissner
| Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
This is the most important patch. It is needed to allow the boostrap to work
again when long double is IEEE 128-bit.
| Date: Fri, 3 Feb 2023 00:49:12 -0500
| From: Michael Meissner
| Subject: [PATCH 1/2] PR target/107299: Fix build issue when long double is
IEEE 128-bit
| Message-ID:
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #3 from Andrew Pinski ---
Did you see this in real code or you just noticed this while looking at code
generation?
1 - 100 of 278 matches
Mail list logo
