https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113393
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:0627d1f5340c693699ad36fa2b741ff11d6f026a
commit r14-7238-g0627d1f5340c693699ad36fa2b741ff11d6f026a
Author: Juzhe-Zhong
Date: Mon Jan
On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> > > Xi Ruoyao wrote at 12:11pm on Monday, January
> > > 15, 2024：
> > > > On Mon, 2024-01-15 at 09:29 +0800,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
在 2024/1/15 下午2:42, Xi Ruoyao 写道:
On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
Xi Ruoyao 于2024年1月15日周一 12:11写道：
On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote:
At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong
Hi Haochen,
on 2024/1/11 16:28, HAO CHEN GUI wrote:
> Hi,
> This patch eliminates unnecessary byte swaps for block clear on P8
> LE. For block clear, all the bytes are set to zero. The byte order
> doesn't make sense. So the alignment of destination could be set to
> the store mode size in
At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> > Xi Ruoyao wrote at 12:11pm on Monday, January
> > 15, 2024：
> > > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote:
> > > > At 21:13 +0800 on Saturday, 2024-01-13, Xi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113388
--- Comment #1 from waffl3x ---
Yeah, looks like a bug. I won't be able to look at it as I am in the
process of moving but it seems like a similar one to PR113348.
Thanks for the report!
This patch fixes the following FAILs:
Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.c-torture/execute/pr68532.c -O0 execution test
FAIL: gcc.c-torture/execute/pr68532.c -O1 execution test
FAIL:
On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> Xi Ruoyao 于2024年1月15日周一 12:11写道：
> >
> > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote:
> > > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
> > > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote：
> > > > >
Xi Ruoyao 于2024年1月15日周一 12:11写道：
>
> On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote:
> > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
> > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote：
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > * gcc.dg/pr104992.c: Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
Bug ID: 113394
Summary: ICE: 'verify_type' failed: type variant with
'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Hi Haochen,
on 2024/1/12 14:48, HAO CHEN GUI wrote:
> Hi,
> On P9 "setb" is used to set the result of block compare. So it works
> with m32 and mpowerpc64. On P8, carry bit is used. So it can't work
> with m32 and mpowerpc64. This patch enables block compare expand for
> m32 and mpowerpc64 on
I think you should also remove riscv_vector_abi
since vector ABI is ratified and we should by default enable vector calling
convention by default.
juzhe.zh...@rivai.ai
From: yanzhang.wang
Date: 2024-01-15 14:00
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; lehua.ding; yanzhang.wang
Hi Haochen,
on 2024/1/10 09:35, HAO CHEN GUI wrote:
> Hi,
> This patch refactors function expand_compare_loop and split it to two
> functions. One is for fixed length and another is for variable length.
> These two functions share some low level common help functions.
I'm expecting refactoring
on 2024/1/12 19:03, Alexandre Oliva wrote:
> On Jan 12, 2024, "Kewen.Lin" wrote:
>
By checking PR112917, IMHO we should keep this unbiasing
guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 &&
TARGET_STACK_BIAS), similar to some existing code special
treating SPARC stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113393
Bug ID: 113393
Summary: RISC-V: Full coverage test bugs for upstream 20240112
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
From: Yanzhang Wang
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-call-args-1-run.c: Delete the
-Wno-psabi.
* gcc.target/riscv/rvv/base/abi-call-args-1.c: Ditto.
* gcc.target/riscv/rvv/base/abi-call-args-2-run.c: Ditto.
*
From: Yanzhang Wang
Thanks the
https://hub.fgit.cf/riscv-non-isa/riscv-elf-psabi-doc/pull/389, we
need not to maintain the psabi checking any more.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_arg_has_vector): Delete.
(riscv_pass_in_vector_p): Delete.
YunQiang Su 于2023年8月25日周五 15:16写道：
>
> When working on LLVM, I found this problem
> https://github.com/llvm/llvm-project/issues/64974.
> Maybe it's time for us to reconsider the way of getting GOT address
> for PIC code.
>
I have my draft patch pushed to GitHub:
$GP is used for expanding GOT load, and in the afterward passes,
we will try to use a temporary register instead.
If sucess, we have no need to store and reload $gp. The example
of failure is that the function calls a preemtive function.
We shouldn't use $GP for any other purpose in the code we
On 1/14/24 16:15, Tobias Burnus wrote:
+@node omp_target_memcpy
+@subsection @code{omp_target_memcpy} -- Copy data between devices
+@table @asis
+@item @emph{Description}:
+This routine tests copies @var{length} of bytes of data from the device
+identified by device number @var{src_device_num}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67819
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote:
> At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
> > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote：
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.dg/pr104992.c: Added additional "-mlsx" compilation
> > > options.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
On Sun, Jan 7, 2024, 5:02 PM xndcn wrote:
> Hi, I found __atomic_float constructor does not clear padding,
> while __compare_exchange assumes it as zeroed padding. So it is easy to
> reproducing a infinite loop in X86-64 with long double type like:
> ---
> -O0 -std=c++23 -mlong-double-80
>
On 2024-01-14 18:51, Julia DeMille wrote:
I'm unsure if my patch actually fixes it with this demo -- I need to
work out how to use a patched GCC without installing it on my system,
but without it breaking from not having things it expects to exist on
the system.
I've gotten this to work, and
On Sat, Jan 13, 2024 at 6:36 AM Andrew Burgess wrote:
>
> Tom Tromey writes:
>
> > When I enable cgen rebuilding in the binutils-gdb tree, the default is
> > to run cgen using 'guile'. However, on my host, guile is guile 2.2,
> > which doesn't work for me -- I have to use guile3.0.
> >
> > This
This patch fixes -70% performance drop from GCC-13.2 to GCC-14 with
-march=rv64gcv in real hardware.
The root cause is incorrect cost model cause inefficient vectorization which
makes us performance drop significantly.
So this patch does:
1. Adjust vector to scalar cost by introducing v to
At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
> At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote：
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr104992.c: Added additional "-mlsx" compilation
> > options.
> > * gcc.dg/signbit-2.c: Dito.
> > *
Update in v2: Add dynmaic lmul test.
This patch fixes the regression between GCC 13.2.0 and trunk GCC (GCC-14)
GCC 13.2.0:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li a0,0
ret
Trunk GCC:
vsetvli a5,zero,e8,mf2,ta,ma
li
On 2024-01-14 01:52, Jonathan Wakely wrote:
The reason for this is that the ChangeLog files are auto-generated from
the git commit messages, not edited by hand. Patches to those files
rarely apply cleanly anyway, because they change so frequently that
patches are stale almost immediately.
Ping. Thanks.
xndcn 于2024年1月8日周一 09:01写道：
> Hi, I found __atomic_float constructor does not clear padding,
> while __compare_exchange assumes it as zeroed padding. So it is easy to
> reproducing a infinite loop in X86-64 with long double type like:
> ---
> -O0 -std=c++23 -mlong-double-80
>
Hi Sandra, hi all,
Sandra Loosemore:
On 1/14/24 07:26, Tobias Burnus wrote:
I have some minor nits about typos and copy-editing.
Thanks. That's the downside of doing editing while being sleepy on a
train. Updated and extended version (documenting also omp_target_memcpy)
is attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #11 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++. I fixed it by
> keeping callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #10 from H.J. Lu ---
(In reply to Lukas Grätz from comment #9)
> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
>
> void
Snapshot gcc-14-20240114 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20240114/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #9 from Lukas Grätz ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #4)
> > > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95987
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-06-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95990
Bug ID: 95990
Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
Product: gcc
Version: 10.0
Status: RESOLVED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95991
Bug ID: 95991
Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
Product: gcc
Version: 10.0
Status: RESOLVED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638
--- Comment #12 from Jack Adrian Zappa ---
Is it possible that
2. If a line comment end in an \ but the next line is a comment, then do
the same thing as is done for a multi-line comment, ignore it as not an
issue.
Could be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
--- Comment #6 from Maciej W. Rozycki ---
Thanks WRT Ada clarification.
Otherwise I don't think there's anything stopping a language definition
from requiring an attempt to modify read-only data to be trapped as an
exceptional condition,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113392
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98953
Andrew Pinski changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113392
Bug ID: 113392
Summary: Missed fold of loading 8 consecutive bytes leading to
a missed byteswap optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
=== libgo Summary ===
# of expected passes195
# of unexpected failures1
/dev/shm/bld2283/./gcc/gccgo version 14.0.1 20240114 (experimental)
[master r14-7229-ged5bf2080c5] (GCC)
Subsequently, I ran LAPACK's test programs (using lapack-3.11.0) with
optimization options -O3
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Disable tests for strdup/strndup on __hpux__
hppa*-*-hpux* doesn't have strdup or strndup.
2024-01-14 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-1.c: Disable tests for strdup/strndup
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Skip several gcc.dg/builtin-dynamic-object-size tests on hppa*-*-hpux*
hppa*-*-hpux* doesn't have strdup or strndup.
2024-01-14 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c: Skip on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #1)
> (In reply to anlauf from comment #0)
> > The dump-tree suggests that the scalarizer sees the loop invariant j,
> > unconditionally dereferences it
This patch fixes three of the four unexpected failures that I'm seeing
in the gcc testsuite on x86_64-pc-linux-gnu. The three FAILs are:
FAIL: gcc.c-torture/execute/fprintf-2.c -O3 -g (test for excess errors)
FAIL: gcc.c-torture/execute/printf-2.c -O3 -g (test for excess errors)
FAIL:
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Fix dg-warning on hppa*64*-*-*
2024-01-14 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/Wattributes-6.c: Fix dg-warning on hppa*64*-*-*.
diff --git a/gcc/testsuite/gcc.dg/Wattributes-6.c
https://gcc.gnu.org/gcc-14/changes.html#avr
Johann
--
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9c9dfa44..8c738683 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -342,7 +342,55 @@ a work-in-progress.
-
+AVR
+
+ On AVR64* and
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Skip several analyzer socket tests on hppa*-*-hpux*
2024-01-14 John David Anglin
gcc/testsuite/ChangeLog:
PR analyzer/113150
* c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Skip
on hppa*-*-hpux*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150
--- Comment #1 from GCC Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:b468821eea8df4890157e816e924244810058cb5
commit r14-7232-gb468821eea8df4890157e816e924244810058cb5
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:48448055fb70862ff3914f8a714ff5c4128e6ced
commit r14-7231-g48448055fb70862ff3914f8a714ff5c4128e6ced
Author: Georg-Johann Lay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113391
Bug ID: 113391
Summary: Assertion failure when MSP430 operand modifier J is
used with a non-constant value
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Bug ID: 113390
Summary: [14 Regression] ICE: in
model_update_limit_points_in_group, at
haifa-sched.cc:1986 with -O2
--param=max-sched-region-insns=200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113389
Bug ID: 113389
Summary: ICE when explicit object parameter is not declared as
the first parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
On 1/14/24 07:26, Tobias Burnus wrote:
This documents two more OpenMP (5.0) routines, omp_pause_resource and
omp_pause_resource_all.
Comments, remarks, suggestions - to the patch or the documentation in general?
I have some minor nits about typos and copy-editing. I assume the formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113388
Bug ID: 113388
Summary: Calling explicit object member function without object
argument inside a function that is not an implicit
object member function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283
--- Comment #11 from Arsen Arsenović ---
could be implemented in libstdc++ when no libc impl is present
Hello All:
This patch add the vecload pass to replace adjacent memory accesses lxv with
lxvp
instructions. This pass is added before ira pass.
vecload pass removes one of the defined adjacent lxv (load) and replace with
lxvp.
Due to removal of one of the defined loads the allocno is has only
On 1/14/24 06:05, Georg-Johann Lay wrote:
Ping #3
RFA: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640140.html
Ping #1 https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640981.html
Ping #2 https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641912.html
This is a patch
mips bootstraps have been broken for a while. They've been triggering
an error about mutually exclusive equal-tests always being false when
building gencondmd.
This was ultimately tracked down to the ior3_mips16_asmacro
pattern. The pattern uses the GPR mode iterator which looks like this:
This documents two more OpenMP (5.0) routines, omp_pause_resource and
omp_pause_resource_all.
Comments, remarks, suggestions - to the patch or the documentation in
general?
Tobias
PS: When looking at it, I found an issue in the spec with regards to a
new constant (post TR12, hence, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113385
--- Comment #3 from Sam James ---
Created attachment 57078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57078=edit
reduced.ii
Attached something a bit smaller but it's not great (not very elegant and too
many warnings).
Ping #3
RFA: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640140.html
Ping #1 https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640981.html
Ping #2 https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641912.html
This is a patch that locates .rodata in flash for some AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #8 from Jonathan Wakely ---
We will do it as a DR against all previous standards, as we do for most DRs.
But closing Bug 90203 was still correct at the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336
Roger Sayle changed:
What|Removed |Added
Last reconfirmed||2024-01-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Roger Sayle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #7 from Lukas Grätz ---
(In reply to H.J. Lu from comment #4)
> When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> most of C++ exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Lukas Grätz changed:
What|Removed |Added
CC||lukas.graetz@tu-darmstadt.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112992
Roger Sayle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Andrew Pinski changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113387
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113387
Bug ID: 113387
Summary: __attribute__ does not mix with [[gnu:]]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #7 from Jan Schultke ---
I've noticed that too by now. What confuses me is that both libc++ and MSVC STL
implement it as if it was a DR, so transparent comparisons work even outside
C++23 mode.
Is it just a collective mistake, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #6 from Andrew Pinski ---
(In reply to Jan Schultke from comment #5)
> My bad again, it's a defect report, so cppreference is fine.
No, the status is C++23 which means it was only voted as part of C++23. as far
as I understand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #5 from Jan Schultke ---
My bad again, it's a defect report, so cppreference is fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #4 from Jan Schultke ---
My bad. https://en.cppreference.com/w/cpp/utility/pair/operator_cmp currently
shows
> template< class T1, class T2, class U1, class U2 >
> bool operator==( const std::pair& lhs, const std::pair& rhs );
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203
--- Comment #5 from Andrew Pinski ---
Note C++23 changes this via
https://cplusplus.github.io/LWG/lwg-defects.html#3865 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
Paul Thomas changed:
What|Removed |Added
Last reconfirmed||2024-01-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #2 from Andrew Pinski ---
(In reply to Jan Schultke from comment #0)
> Clang with -stdlib=libc++ compiles this, as does MSVC. Bug #90203 was
> incorrectly closed.
No PR 90203 was not closed incorrectly as that was what the C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #1 from Jan Schultke ---
https://godbolt.org/z/9x9n4bGKK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Bug ID: 113386
Summary: std::pair comparison operators should be transparent,
but are not in libstdc++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
--- Comment #1 from Paul Thomas ---
(In reply to anlauf from comment #0)
> While discussing a patch for PR89645/99065, the following issue with
> ASSOCIATE and unlimited polymorphic functions was found:
>
>
96 matches
Mail list logo
