https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #7 from chenglulu ---
(In reply to Andrew Pinski from comment #3)
> MIPS nor RISCV does not define a %c either.
These two architectures can also fail under the following conditions:
void
test(void)
{
asm (".long %c0"
Hi Segher,
Thanks for the comments!
on 2022/11/17 02:58, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote:
>> The current handlings in rs6000_emit_vector_compare is a bit
>> complicated to me, especially after we emit vector float
>> comparison insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107686
Richard Biener changed:
What|Removed |Added
Known to fail|13.0|
Summary|[12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #6 from chenglulu ---
(In reply to Andrew Pinski from comment #1)
> %c does not mean anything in loongarch.
>
> The codes are not documented in the documentation for loonarch though but
> they currently only documented in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107679
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #5 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Xi Ruoyao from comment #2)
> > Interestingly it "worked" with GCC 12.2...
No it does not work. I guess I typed the test command in a wrong SSH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #15 from rguenther at suse dot de ---
On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
>
> Andrew Macleod changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #4 from Andrew Pinski ---
(In reply to Xi Ruoyao from comment #2)
> Interestingly it "worked" with GCC 12.2...
I don't see how it could work though.
62ec3b5352b3 (chenglulu 2021-11-27 14:58:21 +0800 4499) default:
62ec3b5352b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #3 from Andrew Pinski ---
MIPS nor RISCV does not define a %c either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
--- Comment #2 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #1)
> %c does not mean anything in loongarch.
>
> The codes are not documented in the documentation for loonarch though but
> they currently only documented in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Hi Segher,
Thanks for the comments!
on 2022/11/17 02:44, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
>> float only comparison operators.
>
> Why? Is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731
Bug ID: 107731
Summary: error: invalid 'asm': invalid use of '%c'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
We used to expand atomic_exchange_n(ptr, new, mem_order) for subword types
into something like:
{
__typeof__(*ptr) t = atomic_load_n(ptr, mem_order);
atomic_compare_exchange_n(ptr, , new, true, mem_order, mem_order);
return t;
}
It's incorrect because another thread may
Hi,
The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. The new expand pattern
"cbranchcc4" is created which intend to match the pattern defined in
"*cbranch", "*cbranch_2insn" and "*creturn". The operand sequence in
"cbranchcc4" is
> Am 17.11.2022 um 05:10 schrieb Tamar Christina via Gcc-patches
> :
>
> Hi All,
>
> At the moment when the VEC_PERMs generated by this match.pd rule is generated
> it creates two different SSA_NAMEs for the folded operand. Because of this it
> the permute switches from a single operand
Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> We can use an array instead of a std::vector, and we can avoid the
> binary search for the common case of a time point after the most recent
> leap second. On one
LGTM. A minor issue is "enabling -fprefetch-loop-arrays at -O3" is not
documented, but AArch64 and i386 are already doing this anyway. We can
add the fact into the doc later.
On Wed, 2022-11-16 at 10:10 +0800, Lulu Cheng wrote:
> v2 -> v3:
> 1. Remove preldx support.
>
>
Hi,
As mentioned in the previous version patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604646.html
The suboptimal code is generated for "assigning from parameter" or
"assigning to return value".
This patch enhances the assignment from parameters like the below
cases:
/case1.c
> I assume the "full permutation" condition is to avoid performing some
> extra operations that would raise exception flags. If so, are there
> conditions (-fno-trapping-math?) where the transformation would be safe
> with arbitrary shuffles?
Yes, that could be an alternative choice with
On Thu, 2022-11-17 at 11:46 +0800, Jinyang He wrote:
> > So we do need an additional dbar for compare-and-exchange, but do
> > not
> > need it for a bare atomic exchange?
> Yes.
Ok, I just noticed we also don't use dbar in atomic_add etc.
I've adjusted the patch a little (in attachment):
On 16/11/22 12:54, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
On 15/11/22 17:17, Jonathan Wakely wrote:
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough.
On 11/7/22 11:58, Palmer Dabbelt wrote:
The docs say we take ISA strings, but that's never really been the case:
at a bare minimum we've required lower case strings, but there's
generally been some subtle differences as well in things like version
handling and such. We talked about removing
Hi All,
At the moment when the VEC_PERMs generated by this match.pd rule is generated
it creates two different SSA_NAMEs for the folded operand. Because of this it
the permute switches from a single operand permute to a two operand permute and
the target may no longer support a permute for this.
On 11/15/22 01:33, jiawei wrote:
This testcase mix exist spill-1.c and adding new fun to check if
there have redundant addi intructions. Idea provided by Jeff Law.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/spill-sp-adjust.c: New test.
I made several
On 2022/11/17 上午11:38, Xi Ruoyao wrote:
On Thu, 2022-11-17 at 10:55 +0800, Jinyang He wrote:
On 2022/11/17 上午9:39, Jinyang He wrote:
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+
On Thu, 2022-11-17 at 10:55 +0800, Jinyang He wrote:
> On 2022/11/17 上午9:39, Jinyang He wrote:
>
> > On 2022/11/16 下午7:46, Xi Ruoyao wrote:
> >
> > > On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
> > >
> > > > > > + return "%G6\\n\\t"
> > > > > > + "1:\\n\\t"
> > > > > > +
On 11/12/22 16:55, Andrew Pinski via Gcc-patches wrote:
On Sat, Nov 12, 2022 at 3:47 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
gcc/ChangeLog:
* value-range.cc (get_bound_with_infinite_markers): New static helper.
(irange::as_string): New definition.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
David Malcolm changed:
What|Removed |Added
Keywords||patch
Status|ASSIGNED
PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with
the combination of -fanalyzer and -Wunused-macros.
The issue is that in c_translation_unit::consider_macro's call to
cpp_create_reader I was passing "ident_hash" for use by the the new
reader, but that takes ownership of that
On 2022/11/17 上午9:39, Jinyang He wrote:
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+ "ll.\\t%0,%1\\n\\t"
+ "and\\t%7,%0,%z3\\n\\t"
+ "or%i5\\t%7,%7,%5\\n\\t"
+
On Fri, Nov 11, 2022 at 5:09 PM Cui,Lili via Gcc-patches
wrote:
>
> From: Lili Cui
>
> Hi Hontao,
>
> This patch is to enable 256 move by pieces for ALDERLAKE and AVX2.
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?
Ok.
>
>
> gcc/Changelog:
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
Kewen Lin changed:
What|Removed |Added
Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107730
Sam James changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Sam James ---
On 11/15/22 09:31, Aldy Hernandez via Gcc-patches wrote:
I know it's past the end of stage1, but I'm afraid we'll drag this
around forever in the GCC12 branch, and it's an easy readbility fix.
p.s. Or if you prefer:
if (!lb_nan && !ub_nan && !maybe_nan && )
r.clear_nan ();
OK for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107730
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 11/16/22 03:26, Manolis Tsamis wrote:
On Sun, Nov 13, 2022 at 3:33 AM Jeff Law via Gcc-patches
wrote:
On 11/7/22 15:07, Palmer Dabbelt wrote:
On Thu, 03 Nov 2022 15:23:28 PDT (-0700), j...@ventanamicro.com wrote:
On 11/2/22 18:26, Palmer Dabbelt wrote:
I also tried to remove that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107730
--- Comment #1 from Sam James ---
Note that if I drop 'static', the warning goes away. Clang does not warn at
all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107730
Bug ID: 107730
Summary: Trivial -Wreturn-type false positive when function
marked static
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #2 from Jeffrey A. Law ---
ACK. And as I mentioned, the RTL form looks like it ought to be caught by the
SH specific code to optimize T reg handling. I don't care enough about the SH
to try and debug a missed optimization though.
So my tester started showing even more regressions on the sh3/sh4 runs
recently (beyond the one recently reported in BZ triggered by some DCE
related changes). Bisection kept showing inconsistent results. I was
starting to think memory management error, but valgrind didn't flag
anything.
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+ "ll.\\t%0,%1\\n\\t"
+ "and\\t%7,%0,%z3\\n\\t"
+ "or%i5\\t%7,%7,%5\\n\\t"
+ "sc.\\t%7,%1\\n\\t"
+ "beqz\\t%7,1b\\n\\t";
Do
On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote:
> On 11/15/22 19:35, Marek Polacek wrote:
> > On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
> > > On 11/12/22 06:53, Marek Polacek wrote:
> > > > In this PR, we are crashing because we've encountered a UDL where a
> >
LGTM, thanks :)
On Thu, Nov 17, 2022 at 5:17 AM Kevin Lee wrote:
>
> l insn condition has been modified based on the thread in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605481.html. The
> lfloor-lecil-inexact checks call instead of scan-assembler-not
> "fcvt.l.s/d" due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
For powerpc64le we need to be able to format both of __ieee128 and
__ibm128, so we need the std::to_chars overloads for both types to be
visible at once. The __ieee128 overloads are always visible in C++23
mode, because they're used to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107720
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107720
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f69a8299c1d95548e1539227fb7b8f5581aeb29b
commit r13-4117-gf69a8299c1d95548e1539227fb7b8f5581aeb29b
Author: Jonathan Wakely
Hi,
r13-3950-g071e428c24ee8c enables O2 small loop unrolling, but it breaks
-fno-unroll-loops for rs6000 with loop_unroll_adjust hook. Adjust the
option handling and target hook accordingly.
Bootstrapped & regtested on powerpc64le-linux-gnu, OK for trunk?
gcc/ChangeLog:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104630
--- Comment #2 from John ---
This issue is still in v12.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
--- Comment #9 from David Malcolm ---
It's a use-after-free of the ident_hash hash_table. Testing a fix...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
Andrew Pinski changed:
What|Removed |Added
Summary|no warning for precise |-Wliteral-range vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #5 from Andrew Pinski ---
Note I think GCC's -Wfloat-equal is more reasonible than Clang's
-Wliteral-range really. The reason is because even if something can be
represented exactly in floating point (e.g. 3.0 or even 0.0), you
Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4115-gff199a859b2a95.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/named-constants-via-command-line.c: New test.
* gcc.dg/analyzer/named-constants-via-macros-3.c: New test.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
--- Comment #3 from Thomas Petazzoni ---
Thanks for the super quick feedback. Could you clarify "Move over, the
functions are not optimized out at -O2 but rather they don't get pulled in
glibc building because another function is referenced." ?
PR analyzer/107711 seems to be a bug in how named constants are looked up
by the analyzer in the C frontend.
To help debug this, this patch extends -fdump-analyzer and
-fdump-analyzer-stderr so that they dump this part of the analyzer's
startup.
Successfully bootstrapped & regrtested on
Backports applied to releases/gcc-11 and releases/gcc-12. Thanks!
Philipp.
On Tue, 15 Nov 2022 at 11:43, Richard Sandiford
wrote:
> Philipp Tomsich writes:
> > Richard,
> >
> > is this OK for backport to GCC-12 and GCC-11?
>
> The fusion part seems potentially risky for a stable branch, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
--- Comment #8 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6e4962810fe5de95b807d1ac675df45a725e31a2
commit r13-4114-g6e4962810fe5de95b807d1ac675df45a725e31a2
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
--- Comment #3 from Saleem Abdulrasool ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > :6:1: warning: unsupported size for integer register
>
> I get that when I use:
> #%0 %1
This totally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> :6:1: warning: unsupported size for integer register
I get that when I use:
#%0 %1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
--- Comment #1 from Andrew Pinski ---
:6:1: warning: unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
Bug ID: 107729
Summary: unhelpful handling for PMF on Itanium ABI for inline
asm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725
--- Comment #4 from David Malcolm ---
Aha thanks: presumably "Ep 350 - The Right Way to Write C++ Code in 2022"?
I'm watching it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107712
--- Comment #3 from cqwrteur ---
(In reply to Jonathan Wakely from comment #2)
> Should be fixed now.
Question about toupper or any functions in ctype.h
These functions are not thread-safe and they do incur a very high cost due to
calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
--- Comment #2 from Andrew Pinski ---
Move over, the functions are not optimized out at -O2 but rather they don't get
pulled in glibc building because another function is referenced.
Either libgcc should be built with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
kargl at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote:
>
> @Steve: please close PR if you think everything is ok.
>
Thanks. I'll close the pr.
--
Steve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107148
Joseph S. Myers changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
Dear all,
I've committed the attached patch for Steve after regtesting.
It obviously checks the types of character length to be integer
before passing them to mpz_*.
Pushed as r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
Thanks,
Harald
@Steve: please close PR if you think everything is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:bdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
commit r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
Author: Steve Kargl
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
--- Comment #5 from Andrew Pinski ---
(In reply to cqwrteur from comment #2)
> BTW. how could i detect this feature being available? I think
>
> #if __has_cpp_attribute(__gnu__::__target__)
>
> #endif
>
> should not be true on targets that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
--- Comment #3 from Andrew Pinski ---
What they do is basically have the resolver always called:
callq __cpu_indicator_init
movl__cpu_model+12(%rip), %eax
andl$1024, %eax # imm = 0x400
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725
--- Comment #3 from Chris Uzdavinis ---
Ah, sorry I didn't realize that. Its use was suggested by Jason Turner in his
most recent C++ Weekly so I started to give it a try. Perhaps there will be an
influx of such premature reports since it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
--- Comment #5 from cqwrteur ---
(In reply to Andrew Pinski from comment #2)
> We have tests for multiversioning and they are passing with BFD ld.
>
> Also multiversioning requires ifunc support which is not implemented for
> Windows (I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Bug ID: 107728
Summary: with -O0, libgcc in the first stage compiler has
reference to libc functions
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106649
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 106649, which changed state.
Bug 106649 Summary: [C++23] P2448 - Relaxing some constexpr restrictions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106649
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106649
--- Comment #1 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c85f8dbb173f45053f6d8849d27adc98d9668769
commit r13-4112-gc85f8dbb173f45053f6d8849d27adc98d9668769
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107455
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
--- Comment #2 from cqwrteur ---
BTW. how could i detect this feature being available? I think
#if __has_cpp_attribute(__gnu__::__target__)
#endif
should not be true on targets that do not support it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
--- Comment #3 from Steve Kargl ---
On Wed, Nov 16, 2022 at 09:16:17PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
--- Comment #1 from cqwrteur ---
Here is how clang deals with it on x86_64-windows-gnu (it is how clang calls
x86_64-w64-mingw32)
https://godbolt.org/z/z5cexGEMK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107727
Bug ID: 107727
Summary: error: multiversioning needs 'ifunc' which is not
supported on this target (x86_64-w64-mingw32 target)
Product: gcc
Version: 13.0
Status:
l insn condition has been modified based on the thread in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605481.html. The
lfloor-lecil-inexact checks call instead of scan-assembler-not
"fcvt.l.s/d" due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107723.
Is this patch good for commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
--- Comment #4 from cqwrteur ---
(In reply to Andrew Pinski from comment #3)
> Also please file an different issue for the non-ifunc case since it is a new
> feature.
https://godbolt.org/z/z5cexGEMK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
David Malcolm changed:
What|Removed |Added
Summary|internal compiler error:|ICE with -fanalyzer with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
Andrew Pinski changed:
What|Removed |Added
Target|x86_64-w64-mingw32, |x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107725
David Malcolm changed:
What|Removed |Added
Blocks||97110
--- Comment #2 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107712
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
--- Comment #1 from cqwrteur ---
#if __has_cpp_attribute(__gnu__::__target__) && defined(__SSE2__) &&
!defined(__AVX2__)
[[__gnu__::__target__("default")]]
#elif __has_cpp_attribute(__gnu__::__flatten__)
[[__gnu__::__flatten__]]
#endif
inline
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is only a partial fix for the PR.
libstdc++-v3/ChangeLog:
PR libstdc++/107720
* include/std/format (__format::_Arg_t): Fix typo in enumerator
name.
(_Arg_value::_S_get): Fix missing semi-colons.
---
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We can use an array instead of a std::vector, and we can avoid the
binary search for the common case of a time point after the most recent
leap second. On one system where I tested this, utc_clock::now() now
takes about 16ns instead of 31ns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107726
Bug ID: 107726
Summary: Multiple bugs related to __gnu__::__target__
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Clang doesn't define __builtin_toupper, so use std::toupper.
Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.
libstdc++-v3/ChangeLog:
PR libstdc++/107712
*
1 - 100 of 305 matches
Mail list logo
