https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #25 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #24)
> On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
Regardless of how one chose to read that part of the standard, fact r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #23 from Iain Sandoe ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
>
> C++ Darwin 32-bit calling a method that returns an 8 by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
--- Comment #5 from g.peterh...@t-online.de ---
add test case (https://godbolt.org/z/q65cWKhWx)
void inc_builtin(array_t& arr)noexcept
{
auto load_cvt = [](const std::float16_t*const ptr) noexcept
{
return __builtin_convertve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108730
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
--- Comment #4 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #3)
> Yes, in sse.md the corresponding expanders are only defined under
> TARGET_AVX512FP16.
Even w/ -mavx512fp16, it's still not vectorized since it relied on
vec_unpac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108918
Bug ID: 108918
Summary: PR107701 breaks windows targets
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917
Bug ID: 108917
Summary: ICE when specifying optimization level for C++
contracts code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108916
Andrew Pinski changed:
What|Removed |Added
Blocks||49774, 53947
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108916
Hongtao.liu changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
--- Comment #1 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108916
Bug ID: 108916
Summary: Miss vectorization for masked gather w/o restrict
qualifier.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
AK changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from AK ---
Adding `__attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> The way to fix uboot code is to change the ll_entry_start/ll_entry_end to:
That is because you cannot take the difference between two distinct objects and
have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
--- Comment #2 from Andrew Pinski ---
ll_start/ll_end needs a similar change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Bug ID: 108915
Summary: invalid pointer access preserved in optimized code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108914
--- Comment #1 from Andreas Kanzler ---
Created attachment 54524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54524&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108914
Bug ID: 108914
Summary: during RTL pass: internal compiler error
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #22 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
Taken from a test Iain had sent me, and I've s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #21 from ibuclaw at gcc dot gnu.org ---
There is something about the Darwin ABI I'm just not getting from looking at
the front-end alone though:
C++ Darwin 32-bit calling a method that returns an 8 byte struct:
```
__Z4testP3Bar:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #2 from Haochen Jiang ---
(In reply to Andrew Stubbs from comment #1)
> I tested it on i686-pc-linux-gnu before I posted the patch, and it was
> working then. Can you be more specific what configuration you were testing,
> please?
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
--- Comment #9 from Haochen Jiang ---
(In reply to Jakub Jelinek from comment #8)
> Should be fixed now.
Sorry for the late reply.
Yes, it fixed for me now. Thx a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #20 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Andrew Pinski from comment #18)
> > > I think the visibility type is POD (assuming D has that concept)
>
> At least the front-end doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881
--- Comment #4 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 54520 [details]
> gcc13-pr108881.patch
>
> Untested fix.
Yes, patch LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108907
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #19 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #18)
> > I think the visibility type is POD (assuming D has that concept)
At least the front-end does.
See dmd/dstruct.d:443
if isPOD return false, TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #18 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to Iain Sandoe from comment #14)
> > > So it would seem that we might want to find a reproducer that w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108905
--- Comment #2 from Lev Veyde ---
So the incorrect filename and line comes from not setting it properly in inline
assembly the macro resolves to?
So it's basically an issue in the Linux kernel source code?
I tried to add .line to the inline as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #17 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Iain Sandoe from comment #14)
> > So it would seem that we might want to find a reproducer that we can look at
> > the various tree dumps and see if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #16 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> (In reply to ibuclaw from comment #13)
> If the caller is passing two regs it seems to me likely that (for some
> reason it thinks that the value is returned via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #15 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #14)
> So it would seem that we might want to find a reproducer that we can look at
> the various tree dumps and see if/where an sret is introduced?
>
> (if that's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #14 from Iain Sandoe ---
(In reply to ibuclaw from comment #13)
> Confirmed, D is doing NRVO return whereas C++ isn't.
I am not sure that the NVRO is the issue (it is correct ABI for an 8 byte
struct to be returned in EAX:EDX). The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #13 from ibuclaw at gcc dot gnu.org ---
Confirmed, D is doing NRVO return whereas C++ isn't.
gdc-11 codegen of the `visible` method:
---
struct Visibility visible (struct AggregateDeclaration * const this)
{
return = this->visibi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108913
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
Andrew Pinski changed:
What|Removed |Added
CC||mike at mnmoran dot org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108913
Bug ID: 108913
Summary: GCC 12.1.0 h8300 ICE building libstdc++
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Looks like a bad mismatch between C++ and D.
When C++ calls the method, it pushes one register. When D calls it, pushes
two.
Looks like the method itself returns the result in 2 registers as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
--- Comment #5 from Andrew Pinski ---
(In reply to Wan-Teh Chang from comment #4)
> Andrew: Thank you very much for the quick reply.
>
> I am also curious about the 15 number. Do you know why the compiler seems to
> think cfg->stage_num_col and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
--- Comment #4 from Wan-Teh Chang ---
Andrew: Thank you very much for the quick reply.
I am also curious about the 15 number. Do you know why the compiler seems to
think cfg->stage_num_col and cfg->stage_num_row can be equal to 15? I.e., why
do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
--- Comment #3 from Andrew Pinski ---
(In reply to Wan-Teh Chang from comment #1)
> Also, I don't get these warnings if I compile with /usr/bin/cc on my Debian
> x86_64 GNU/Linux system, which has the following verison:
That is because the auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
--- Comment #2 from Andrew Pinski ---
So the vectorizer is over vectorizing this code slightly.
The easiest fix is at add:
if (stage_num_col > 12) __builtin_unreachable();
and
if (stage_num_row > 12) __builtin_unreachable();
I though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
--- Comment #1 from Wan-Teh Chang ---
If I increase the size of the `stage_range_col` and `stage_range_row` arrays in
the `TXFM_2D_FLIP_CFG` struct from 12 to 13, 14, 15, the warning messages
change and eventually disappear when the array size b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108890
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7423f5b56ad436f51ac1b9defb954e2bdc5b06ab
commit r13-6307-g7423f5b56ad436f51ac1b9defb954e2bdc5b06ab
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108912
Bug ID: 108912
Summary: A -Wstringop-overflow false positive in
aarch64-linux-gnu-gcc 12.2.0
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108891
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #17 from Kurt Garloff ---
jIt fixes it. Fix committed to git (on bad old sf.net).
Will release new dd_rescue tomorrow ...
Thanks, Martin, Jakub, Andrew for analyzing this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #4 from Jakub Jelinek ---
There is another bug, in darktable actually such overaligned pointer isn't
passed, but it is cvise reduced into:
$ cat color_picker.c
void
bar (void)
{
float *__attribute__((aligned(64))) x;
}
$ cat color_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
Bug ID: 108911
Summary: 0xe+100 gives talks about an impossible literal
operator in error message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
--- Comment #27 from Andrew Pinski ---
Something like this should improve the diagnostic, note the patch needs to be
improved for wrapping:
diff --git a/libcpp/expr.cc b/libcpp/expr.cc
index 6e5bf68eae9..f70be382dd4 100644
--- a/libcpp/expr.cc
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
--- Comment #1 from Eric Reischer ---
One more:
--- gcc-12.2.0/gcc/ada/gcc-interface/Makefile.in2022-08-19
04:09:52.352659553 -0400
+++ gcc-12.2.0-fixed/gcc/ada/gcc-interface/Makefile.in 2023-02-23
16:27:59.604161728 -0500
@@ -616,7 +6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108908
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108145
--- Comment #6 from Vladimir Makarov ---
FYI, I think my patch did not cause this problem.
I've just check fresh trunk (w/o my patch and the compilation still fails).
So the PR probably should be still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108908
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-02-23
Summary|[13 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
> I'd keep its current behavior, perhaps except for -fsanitize=bounds-strict
> -fstrict-flex-arrays{,=3} so that -fsanitize=bounds
> -fstrict-flex-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
Andrew Pinski changed:
What|Removed |Added
Severity|normal |blocker
--- Comment #1 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #10 from Jakub Jelinek ---
(In reply to qinzhao from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Well, -fsanitize=bounds-strict certainly shouldn't imply
> > -fstrict-flex-arrays=2,
> > it should just treat [1] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, -fsanitize=bounds-strict certainly shouldn't imply
> -fstrict-flex-arrays=2,
> it should just treat [1] and [4] (but I think it does even [0] r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #3 from Jakub Jelinek ---
As I've tried to explain in the past, C/C++ considers float * and float
*__attribute__((aligned (64))) types to be compatible, similarly to int and int
__attribute__((aligned (64))), so in calling convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
kurt at garloff dot de changed:
What|Removed |Added
CC||kurt at garloff dot de
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Andrew Pinski changed:
What|Removed |Added
Target Milestone|13.0|12.3
Summary|[13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #1 from Andrew Pinski ---
What I don't understand is how the alignment of the function argument 64 bytes
aligned being taken into account here ...
The alignment of the argument type is still 4 byte aligned even because of the
declara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Bug ID: 108910
Summary: [13 Regression] Further ICE in aarch64_layout_arg
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
--- Comment #13 from Andrew Pinski ---
Note C23 has the following under "4. Conformance":
The implementation shall not successfully translate a preprocessing translation
unit containing a
#error preprocessing directive unless it is part of a grou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
Andrew Pinski changed:
What|Removed |Added
Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #26 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #25)
> Created attachment 54516 [details]
> Proposed fix version 6
>
> Version 6 (more coroutine tests) and RTint.mod with more descriptive
> variable names.
This does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Bug ID: 108909
Summary: Build process does not honor discovered path to
"gnatmake" and "gnatlink"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:a1f70114f9bae5a1dbcec4b556c16716601fccf1
commit r11-10543-ga1f70114f9bae5a1dbcec4b556c16716601fccf1
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #8 from Jakub Jelinek ---
(In reply to qinzhao from comment #7)
> 1. let -fstrict-flex-arrays=N to control the behavior of -fsanitize=bounds;
I'm ok with that.
> 2. -fsanitize=bounds-strict actually is an alias of -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108908
--- Comment #1 from Andrew Pinski ---
Was this not fixed by r13-6296-g31cc5821223a096ef61743bff520f4a0dbba5872 (aka
PR 10 )?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108908
Bug ID: 108908
Summary: [13 regression] r13-6278-g3da77f217c8b20 causes ICE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108907
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108907
Bug ID: 108907
Summary: ira-color.cc:3028:1: error: definition in block 5
follows the use
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #24 from joseph at codesourcery dot com ---
On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> In this code
>
> static const int y = 1;
> static int x = y;
>
> y is not an integer constant expression, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108895
--- Comment #2 from Henry Le Berre ---
Thank you Thomas for your swift reply! I would also like to thank you for
fixing the previous bug I had reported, it is sincerely appreciated. I will
take a look at the devel/omp/gcc-12 branch to see how mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107818
--- Comment #1 from Andrew Pinski ---
include/line-map.h:const location_t LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES =
0x5000;
include/line-map.h:const location_t LINE_MAP_MAX_LOCATION_WITH_COLS =
0x6000;
include/line-map.h:const location_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #5 from Tobias Burnus ---
The warning itself is bogus (false positive in the middle end).
I get:
Warning: ‘f.dim[idx.1_32].lbound’ may be used uninitialized
[-Wmaybe-uninitialized]
If I now look at the 021t.ssa dump, I see:
f.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108906
Bug ID: 108906
Summary: Bogus may be used uninitialized warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #11 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #10)
> std::move(x,y,z) and std::copy(z,y,z) use the same underlying
> implementation, so it does have the same issue, but will be fixed by the
> same change.
Rig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #10 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> I suspect std::move has the same issue too. The ability to use memmove with
> trivial copyable subobjects ...
std::move(x,y,z) and std::copy(z,y,z) use the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #9 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #5)
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> stl_algobase.h#L417-L437
>
> Is the extent of the fix just to add another b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108902
--- Comment #2 from Andrew Pinski ---
-std=c++23 -march=x86-64-v3 -O3 -mno-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:8e171d840584a564993201101cd1f2e920e7aecb
commit r12-9200-g8e171d840584a564993201101cd1f2e920e7aecb
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
--- Comment #5 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> *** Bug 108893 has been marked as a duplicate of this bug. ***
N.B. this one is about __attribute__((access(read_only, 1))) not nonnull. The
docs already seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5592679df783547049efc6d73727c5ff809ec302
commit r13-6306-g5592679df783547049efc6d73727c5ff809ec302
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
--- Comment #5 from Georg-Johann Lay ---
... also tried v9.2 via
https://godbolt.org/z/9r3vMj1e3
and just like with v8.5, the respective block is around asm line 350.
1 - 100 of 171 matches
Mail list logo
