https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #8 from Christophe Peyret ---
try this on Mac with Fortran 15.1.0
program main
use iso_c_binding
implicit none
character(len=:), pointer :: str =>null()
allocate( character(len=11) :: str )
str = “0123456789x”
print “((A))", s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:7fd6cb3c8488465ae0529f543f5309584961503d
commit r16-1667-g7fd6cb3c8488465ae0529f543f5309584961503d
Author: H.J. Lu
Date: Wed Jun 25 07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
--- Comment #5 from H.J. Lu ---
Fixed f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120816
--- Comment #1 from H.J. Lu ---
Created attachment 61709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61709&action=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120816
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120816
Bug ID: 120816
Summary: [16 Regression] tcpsock_test.go:684:28: error: flow
control insn inside a basic block
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
--- Comment #3 from H.J. Lu ---
(In reply to Hongtao Liu from comment #2)
> Maybe we should have something like mtune=intel_p and mtune=intel_e, P-core
> and E-core are quite different from each other, mtune=intel maybe not
> sufficient.
We can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
--- Comment #2 from Hongtao Liu ---
Maybe we should have something like mtune=intel_p and mtune=intel_e, P-core and
E-core are quite different from each other, mtune=intel maybe not sufficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120189
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2025-06-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120720
--- Comment #6 from Simon H. ---
Oops, right you are. My check was nonsense. That makes far more sense.
But for the builtins it's trying to compile line 40, using the function as an
initialiser for a constexpr variable, which causes problems;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120756
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
Benjamin Schulz changed:
What|Removed |Added
Attachment #61703|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
Benjamin Schulz changed:
What|Removed |Added
Attachment #61704|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
--- Comment #4 from Benjamin Schulz ---
what is also interesting:
template
bool matrix_multiply_dot( mdspan& A, mdspan& B, mdspan&
C, bool on_gpu=false,bool default_device=true,int devicenum=0)
you can use the upload member functions of md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120815
Bug ID: 120815
Summary: Update -mtune=intel to -mtune=alderlake
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #6)
> (In reply to kargls from comment #5)
> > (In reply to kargls from comment #4)
> > > (In reply to anlauf from comment #3)
> > >
> > > troutmask:sgk[215] gfcx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
--- Comment #3 from Jeffrey A. Law ---
I think that's reasonable as well and one of the options discussed weeks ago in
the patchwork call.
I was thinking that having the relevant intrinsics set the flag was slightly
better solution because it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216
--- Comment #4 from Benjamin Schulz ---
I did a benchmark here with my new card :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120679
In many nvidia graphics cards on a pci bus, unified shared memory, in form of
hmm is currently not very suit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:92e1893e0155b6b3baef2a935efd5936d23a67ea
commit r16-1659-g92e1893e0155b6b3baef2a935efd5936d23a67ea
Author: Paul-Antoine Arras
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120743
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120724
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120756
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120756
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
--- Comment #3 from Benjamin Schulz ---
I want to note that if one comments out
//A.device_upload(true);
//B.device_upload(true);
//C.device_alloc(true);
and
// C.host_update(true);
in
bool matrix_multiply_dot( mdspan& A, mdspan& B,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120798
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-06-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120742
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> (In reply to kargls from comment #4)
> > (In reply to anlauf from comment #3)
> >
> > troutmask:sgk[215] gfcx --version
> > GNU Fortran (GCC) 16.0.0 2025052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120795
--- Comment #10 from Andrew Pinski ---
This might be slightly smaller, (removes c++20 specific stuff) (I can't test it
with the failing case):
```
int a;
void b();
struct e {
int ab;
int d() { return ab; }
};
struct f {
e g;
auto d() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #13 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Siddhesh Poyarekar from comment #11)
> > OK, so we don't really need a FAM based reproducer either, here's one
> > without it. FAM just make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #16 from Jakub Jelinek ---
If it happens at runtime, better testcase would be to test it at runtime...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #5 from kargls at comcast dot net ---
(In reply to kargls from comment #4)
> (In reply to anlauf from comment #3)
>
> troutmask:sgk[215] gfcx --version
> GNU Fortran (GCC) 16.0.0 20250528 (experimental)
>
There are a couple of stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Andre Vehreschild from comment #1)
> Confirmed, but this is not coarray dependent. For me it also crashes without
> -fcoarray=single.
Indeed. valgrind reports an invalid read with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #15 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #14)
>
> So, __bdos returns something larger than that? That would be weird.
> Or do the two calls result in different results?
It's basically comment 9; __bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #1 from Vineet Gupta ---
Perhaps worth looking into the new RISC-V pass fold-memory-offset ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #2 from Jeffrey A. Law ---
And combine. Though I suspect this is fallout from the way we're handling
2*simm12 cases with a define_insn_and_split. I've got a plan there and I'm
just waiting for Shreya to wrap up her current task be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #14 from Jakub Jelinek ---
(In reply to Siddhesh Poyarekar from comment #13)
> (In reply to Jakub Jelinek from comment #12)
> > (In reply to Siddhesh Poyarekar from comment #11)
> > > OK, so we don't really need a FAM based reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #4 from kargls at comcast dot net ---
(In reply to anlauf from comment #3)
> (In reply to kargls from comment #2)
> > Harald, there's a bug (at least it fails on FreeBSD).Here's
> > a testcase based on the original code. On Free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #10 from Siddhesh Poyarekar ---
Minimal reproducer, I've written this independently, not reduced from the
preprocessed source, but I'm pretty sure this is essentially what it is:
typedef __SIZE_TYPE__ size_t;
struct inner
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #11 from Siddhesh Poyarekar ---
OK, so we don't really need a FAM based reproducer either, here's one without
it. FAM just makes this case more likely because due to it, __bdos succeeds
more often in the kernel code:
typedef __SIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #1 from anlauf at gcc dot gnu.org ---
Works as expected on Linux.
What happens if you replace C_NEW_LINE by something different,
like c_carriage_return, or c_null_char, and pipe the output
through "cat -v"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120795
--- Comment #9 from Sam James ---
```
int a;
void b();
struct e {
int ab;
int d() { return ab; }
};
struct f {
e g;
auto d() { return g.d(); }
};
template struct i : h {
f j;
template int ad(ac) {
unsigned char k = j.d();
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120810
--- Comment #2 from Jonathan Wakely ---
If we had a working time_get::do_date_order (see Bug 9635) then we could
implement DR 461 something like this:
--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #2)
> Harald, there's a bug (at least it fails on FreeBSD).Here's
> a testcase based on the original code. On FreeBSD, I see
>
> % gfcx -o z a.f90 && ./z
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120743
--- Comment #8 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5bc92717b804483a17dd5095f8b6d4fd75a472b1
commit r16-1658-g5bc92717b804483a17dd5095f8b6d4fd75a472b1
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120743
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=120812
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> We could also have a custom facet derived from time_get that we store in the
> std::locale when it is created by name from a C locale, and store a
> dateorde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
Bug ID: 120814
Summary: gcc does not compute on nvptx device when the loop is
given over a variable whose pointer was offloaded in
another function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711
--- Comment #2 from anlauf at gcc dot gnu.org ---
There is another recent PR on using array constructors of derived types
with allocatable character components, quite similar to this one.
Cannot find it now, but very likely related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120813
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.2
Summary|[15/16 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518
--- Comment #16 from Benjamin Schulz ---
Hi @all
I just wanted to give you an update how my library progresses and what
additional bugs I've found in GCC so far.
Since some of you are familiar with my code, perhaps you can help to fix them,
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89173
--- Comment #2 from Jeffrey A. Law ---
Still happens on the BPI. But I think we have bigger issues to resolve, so
deferring further action for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
--- Comment #1 from Benjamin Schulz ---
Created attachment 61704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61704&action=edit
mainn_omp.cpp contains the main program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814
--- Comment #2 from Benjamin Schulz ---
Created attachment 61705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61705&action=edit
cmakelists.txt
cmakelists.txt to switch and see the different results between gcc-15.1 and
clang-20.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
--- Comment #16 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:415bad120d8f21cd754d827da9e3d5e1fbe68d4c
commit r12-11224-g415bad120d8f21cd754d827da9e3d5e1fbe68d4c
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
Bug ID: 120811
Summary: RISC-V: missed load offset
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120773
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ed7fc2b29ead88be30b40ec2c3c51495200b08c4
commit r16-1657-ged7fc2b29ead88be30b40ec2c3c51495200b08c4
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120773
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 120773, which changed state.
Bug 120773 Summary: [C++26] P3618R0 - Allow attaching main to the global module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120773
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 120773, which changed state.
Bug 120773 Summary: [C++26] P3618R0 - Allow attaching main to the global module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120773
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120813
Bug ID: 120813
Summary: [15/16 Regression] RISC-V: Miscompile at -O[23]
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
Bug ID: 120812
Summary: [regression] buffer(80:80) = C_NEW_LINE not working
with gfortran 15.1 under Mac
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120807
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119706
--- Comment #16 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:75f255c11f7e5a5099ad909606e21ec6bf9b82cc
commit r12-11230-g75f255c11f7e5a5099ad909606e21ec6bf9b82cc
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
Richard Biener changed:
What|Removed |Added
Known to work||12.4.1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120786
--- Comment #2 from Simon Sobisch ---
Just keep in mind that a , and ; are valid separators as well, not only spaces
(they can be inserted nearly every place where a space can, with the exception
of places where they are required).
Rechecked wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120743
Andre Vehreschild changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120809
Bug ID: 120809
Summary: gcc.dg/analyzer/state-diagram-5.c fail starting with
r16-1631-g2334d30cd8feac
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |merzlyakovao at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #12 from Jeffrey A. Law ---
So this is probably still an issue given we're not supposed to use lock-free
and locked sequences simultaneously on any given object. However, given this
only affects us when we don't have the "A", c#2 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104102
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120809
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120809
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120804
--- Comment #1 from Simon Sobisch ---
happening in general, not only with literals:
error: invalid SET T02-IND (FldNumericDisplay) TO T01-IND (FldNumericDisplay):
not a field index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120750
Ondřej Machota changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120810
--- Comment #1 from Jonathan Wakely ---
Frankly, std::time_get::do_date_order() seems unusable and should be
deprecated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120810
Bug ID: 120810
Summary: [DR 461] std::time_get::do_get_date should consider
date_order()
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120745
Ondřej Machota changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738
--- Comment #9 from Kishan Parmar ---
I've went through the RTLs for both PowerPC LE and BE. Whether r3 is used or
not now depends on the reload pass.
In LE, reload often removes the extra copies added by combine. In BE, that
extra instruction re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:6258d3f06740c3a77cd7a91606107451d71df68d
commit r12-11221-g6258d3f06740c3a77cd7a91606107451d71df68d
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2003-12-01 00:55:30 |2025-6-24
--- Comment #11 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808
--- Comment #1 from Andrew Pinski ---
Hmm, I think there is a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808
Bug ID: 120808
Summary: SLP unable to combine .FMA and .FMS to VEC_FMADDSUB
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
Palmer Dabbelt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |palmer at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113833, which changed state.
Bug 113833 Summary: 435.gromacs fails verification on with -Ofast
-march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104102
Palmer Dabbelt changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #9 from Siddhesh Poyarekar ---
I haven't properly reduced this yet, but the key difference appears to be this:
- ifmsh_2 = &MEM[(struct ieee80211_sub_if_data *)dev_1(D) + 2624B].u.mesh;
- _6 = &MEM[(struct ieee80211_sub_if_data *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110
--- Comment #17 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4f63fd4b663bdde39524129dfa458c60b2d67133
commit r12-11218-g4f63fd4b663bdde39524129dfa458c60b2d67133
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #10 from Filip Kastl ---
> Given the nature of the change that caused this (trimming integral ranges
> bounds to match the bitmasks) its probable that a smaller range had some
> other pass make a different decision.
Yeah, I also t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120620
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #9 from Filip Kastl ---
Ok, I'll try to find out from which file (maybe even from which function) the
numerical error originates (thanks for the tips, Sam). It will take some time
though since all of the Zen4/5 machines I have avail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120802
Richard Biener changed:
What|Removed |Added
Known to fail||14.3.0, 15.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117113
--- Comment #8 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:f4dbdeabb2944d014d506a537a576a6f9a1f4c1f
commit r12-11225-gf4dbdeabb2944d014d506a537a576a6f9a1f4c1f
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120806
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711
Andre Vehreschild changed:
What|Removed |Added
Summary|[15/16 regression] Growing |[14/15/16 regression]
1 - 100 of 182 matches
Mail list logo
