https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #14 from Yang Yujie ---
Is it not really necessary for now, since there is no LSX/LASX support in GCC
12 / 13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #18 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:7924e352523b37155ed9d76dc426701de9d11a22
commit r14-9884-g7924e352523b37155ed9d76dc426701de9d11a22
Author: Peter Bergner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114661
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #6 from Andrew Pinski ---
Note fixing the `!A ? B : C` pattern generates worse code in this case but that
is a different issue where we don't convert `a <= 2` into `a == 1` if we know
only 1 could be the value that works (I have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #17 from Jonathan Wakely ---
And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if
I'm reading it correctly, some European zones and the US zones can be used in
$TZ with libc++ but most IANA zones won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
Nathaniel Shead changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 99377, which changed state.
Bug 99377 Summary: [modules] undefined std::string_view::empty() if referenced
in inline exported function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 107068, which changed state.
Bug 107068 Summary: Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #4 from kugan at gcc dot gnu.org ---
This particular loop has loop->safelen set to 16. Does this mean this can never
be loop vectorized for VLA?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #15 from Jonathan Wakely ---
(In reply to Hristo Venev from comment #13)
> > $TZ allows you to override it per-process (and even change it during the
> > lifetime of a process by using setenv and tzset). We don't support that for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #18 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #16)
> ... incorrectly though?
Given that you have expressed your view that *any* attempt at using TZ is
inherently incorrect, I am not surprised that you view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114671
Bug ID: 114671
Summary: [RISC-V] -fvar-tracking -gas-locview-support -ggdb
emits a non-constant .uleb128
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #13 from Li Pan ---
overriding TARGET_CLASS_LIKELY_SPILLED_P hook may not be a fix as it will
generate sorts of spill for the below sample code.
vbool2_t test_vmfge_vf_f16m8_b2(vfloat16m8_t op1, float16_t op2, size_t vl) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
Bug ID: 114668
Summary: [14] RISC-V rv64gcv: miscompile at -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114670
Bug ID: 114670
Summary: `(a ^ 1) <= 3` can be optimized to `a <= 3`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> I would expect TZ=:Europe/London to work according to POSIX,
Well, POSIX says ":characters" is implementation-defined, but for Glibc it
looks up an IANA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #20 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Jonathan Wakely from comment #16)
> > ... incorrectly though?
>
> Given that you have expressed your view that *any* attempt at using TZ is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #23 from Jonathan Wakely ---
Re https://github.com/cplusplus/draft/issues/6922
It can't possibly mean that the returned time zone *needs* to be the same as
the C library, because that's impossible in general, because the C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104040
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:0774240b4df9a9bc48ce33a9625788e402498f5a
commit r14-9883-g0774240b4df9a9bc48ce33a9625788e402498f5a
Author: Nathaniel Shead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #8 from Kewen Lin ---
(In reply to Peter Bergner from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Pre-IRA fix was done to specifically reject this:
> > https://inbox.sourceware.org/gcc-patches/
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #21 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Harald van Dijk from comment #18)
> > (In reply to Jonathan Wakely from comment #16)
> > > ... incorrectly though?
> >
> > Given that you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
--- Comment #1 from Andrew Pinski ---
Looks to be working on aarch64 (both with/without SVE):
```
[apinski@xeond2 upstream-cross-aarch64]$ ./install/bin/aarch64-linux-gnu-gcc
-O3 -fno-vect-cost-model t6.c -static -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:92b38ec84f2990d217f036dc6c5a32cde5ecfb93
commit r14-9879-g92b38ec84f2990d217f036dc6c5a32cde5ecfb93
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #16 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Jonathan Wakely from comment #8)
> > None of libstdc++, LLVM libc++, MSVC STL or the
> > date/tz.h reference implementation uses $TZ for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #22 from Jonathan Wakely ---
I do still consider it incorrect.
But what I mean re libc++ is that *even ignoring* the general problems with
using TZ, *their implementation* of using TZ isn't even correct. If the
intention is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #3 from kugan at gcc dot gnu.org ---
For SVE mode in vect_analyze_loop_2, we have
(gdb) p min_vf
$15 = {coeffs = {4, 4}}
(gdb) p max_vf
$16 = 16
Thus maybe_lt (max_vf, min_vf)) is false. This results in bad data dependence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 104040, which changed state.
Bug 104040 Summary: linker: when exported template class from module is used in
several .cpp with same tpl arg ~ undefined reference to not default non-inline
destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #2 from kugan at gcc dot gnu.org ---
Thanks. I see the following in the log:
test.cpp:33:53: missed: not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed: bad operation or
-trunk-r14-9877-20240409180605-g1f719aa7c0d-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240409 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102918
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114669
Bug ID: 114669
Summary: use >= comparison when testing high bits
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377
--- Comment #17 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:77c0b5b23f91404004a9bf710981f6d615b63f57
commit r14-9881-g77c0b5b23f91404004a9bf710981f6d615b63f57
Author: Nathaniel Shead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #15 from Kewen Lin ---
(In reply to Michael Matz from comment #14)
> Hmm? But this is not how the global-to-local hand-off is implemented (and
> expected by tooling): a fall-through. The global entry sets up the GOT
> register,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
Xi Ruoyao changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #3 from Andrew Pinski ---
With match.pd:7103 disable we get:
Folding statement: _2 = (long unsigned int) _1;
Global Exported: _2 = [irange] long unsigned int [0, 0][+INF, +INF]
Not folded
Folding statement: _3 = _2 ^ 1;
Matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
--- Comment #4 from Andrew Pinski ---
Note the other pattern which uses logical_inverted_value where it depends on
the type does:
/* -(type)!A -> (type)A - 1. */
(simplify
(negate (convert?:s (logical_inverted_value:s @0)))
(if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114667
Bug ID: 114667
Summary: `gcc -O2 t.c -fdump-tree-optimized=/dev/stdout
-fdump-tree-all` produces `error: could not open dump
file`
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114666
Andrew Pinski changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112878
--- Comment #5 from Indu Bhagat ---
Hmm, thanks. Using sorry in some cases will be a viable option.
For this specific case though, I am thinking emitting CTF_K_UNKNOWN instead
should be okay. We have precedent in CTF generation in GCC where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #29 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #10 from Li Pan ---
The #define FUNCTION_VALUE_REGNO_P(N) ((N) == GP_RETURN || (N) == FP_RETURN) of
the riscv backend doesn't honor vector mode. Then the below part
370 if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #8 from Jonathan Wakely ---
Yes, if an application assumes that chrono::current_zone matches $TZ, that's a
bug in the application. None of libstdc++, LLVM libc++, MSVC STL or the
date/tz.h reference implementation uses $TZ for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #11 from Hristo Venev ---
I never said that reading $TZ is easy, just that not doing it is (in my
opinion) wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a79d13a01f8cbb99fb45bf3f3ffc62c99ee0b05e
commit r14-9869-ga79d13a01f8cbb99fb45bf3f3ffc62c99ee0b05e
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #12 from GCC Commits ---
The master branch has been updated by LuluCheng :
https://gcc.gnu.org/g:8657d76d583f0f87000e9003ba75922f2bbe4455
commit r14-9866-g8657d76d583f0f87000e9003ba75922f2bbe4455
Author: Yang Yujie
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #10 from Xi Ruoyao ---
> rust's `chrono`
Note that this is really a bad example because of CVE-2020-26235.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Pierre-Emmanuel Patry from comment #2)
> While you are at it, it would be useful to add a link to the rust langauge
> specification (like there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627
--- Comment #2 from GCC Commits ---
The master branch has been updated by J?rgen Kvalsvik :
https://gcc.gnu.org/g:a2447556a5405d2cde20afc134b90cd1d199ce04
commit r14-9864-ga2447556a5405d2cde20afc134b90cd1d199ce04
Author: Jørgen Kvalsvik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
--- Comment #9 from GCC Commits ---
The master branch has been updated by J?rgen Kvalsvik :
https://gcc.gnu.org/g:2daeb89d6f025d6daf7e560575863b3280120be8
commit r14-9863-g2daeb89d6f025d6daf7e560575863b3280120be8
Author: Jørgen Kvalsvik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> /* If we didn't see a full return value copy, verify that there
>is a plausible reason for this. If some, but not all of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> Fixed I suppose.
Yes - I plan backport the patch to at least gcc-13.
There is still problem with loop bounds. I am testing patch on that and
then we should be (finally) finally safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #76 from Jan Hubicka ---
There is still problem with loop bounds. I am testing patch on that and
then we should be (finally) finally safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114652
Bug ID: 114652
Summary: g++ fails to compile the ceres-solver-2.2.0 project:
error: use of built-in trait '__remove_cvref(_Tp)' in
function signature; use library traits instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93537
--- Comment #4 from Andrew Pinski ---
Created attachment 57909
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57909=edit
Reduced testcase
This as reduced as I could get it for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114652
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #9 from Hristo Venev ---
I stumbled upon this comment in the library you linked:
https://github.com/HowardHinnant/date/blob/0e65940a7fbc4ed617a1ee111a60311eccbead9a/include/date/tz.h#L35
That comment is wrong in its explanation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
Bug ID: 114653
Summary: Not vectoring the loop with openmp reduction.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114654
Bug ID: 114654
Summary: Alias template cannot be found
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
--- Comment #8 from Jan Hubicka ---
I am not sure this ought to be P1:
- the compilation technically is finite, but not in reasonable time
- it is possible to adjust the testcas (do early inlining manually) and get
same infinite build on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #13 from Xi Ruoyao ---
Will we back port the fix to 13 and 12?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106
--- Comment #9 from Andrew Pinski ---
Also note both EDG is able to handle this correctly (clang was already
mentioned).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106
Andrew Pinski changed:
What|Removed |Added
CC||rowe-gcc at excc dot ex.ac.uk
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70257
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #7 from Marc Poulhiès ---
There's no language spec yet, it's WIP:
https://github.com/rust-lang/rust/issues/113527
Currently, the reference is rustc and the goal is to match its current
behavior.
I think the frontend is not listed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
Andrew Pinski changed:
What|Removed |Added
CC||marco at technoboredom dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45115
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114604
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93537
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-invalid-code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101545
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #8 from Li Pan ---
Find an even simpler code for reproduction.
#include
extern unsigned long get_vl ();
vbool16_t test (vuint64m4_t a)
{
unsigned long b;
return __riscv_vmsne_vx_u64m4_b16 (a, b, get_vl ());
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114652
--- Comment #1 from Andrew Pinski ---
This might be a bug in LLVM's libc++ ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7dd1f9d2ec422173f490d91b9173d4fa5d32d909
commit r14-9859-g7dd1f9d2ec422173f490d91b9173d4fa5d32d909
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
Bug 89990 depends on bug 88058, which changed state.
Bug 88058 Summary: gcc fails to detect use of out of scope variable ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272
Andrew Pinski changed:
What|Removed |Added
CC||dgilbert at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 89990, which changed state.
Bug 89990 Summary: request warning: Use of out of scope compound literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cfed80b9e4f562c99679739548df9369117dd791
commit r14-9861-gcfed80b9e4f562c99679739548df9369117dd791
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272
--- Comment #10 from Andrew Pinski ---
*** Bug 88058 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93537
Andrew Pinski changed:
What|Removed |Added
Summary|gcc 9.2 takes a |[11/12 Regression] gcc 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114651
Bug ID: 114651
Summary: Missed optimization: (c - y) + ((a - c) - (b - y)) =>
a-b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:481ba4fb5fce8257f5dbeb994dac2748c0237fa2
commit r14-9853-g481ba4fb5fce8257f5dbeb994dac2748c0237fa2
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52534
--- Comment #4 from Andrew Pinski ---
Interesting clang accepts it also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
--- Comment #7 from Andrew Pinski ---
>From PR 108635 (via PR 45115), a C++20 testcase where we should be able to
optimize into one call of `operator<=>`:
#include
struct S
{
std::weak_ordering operator<=>(const S&) const
1 - 100 of 178 matches
Mail list logo
