https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104256
Bug ID: 104256
Summary: ICE in validate_condition_mode, at
config/rs6000/rs6000.cc:11354
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #32 from Hongtao.liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589168.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059
--- Comment #6 from Hongtao.liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589209.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161
Josh Stone changed:
What|Removed |Added
CC||jistone at redhat dot com
--- Comment #5
Configuring with --enable-default-ssp triggers various testsuite
failures. These contain asm statements that are not compatible with
-fstack-protector. Adding -fno-stack-protector to dg-options to
work around this issue.
Tested on x86_64-linux.
2022-01-26 Allan McRae
PR
On 1/26/22 18:55, Marek Polacek wrote:
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto ()[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto ()[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct]
prohibits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
--- Comment #2 from joseph at codesourcery dot com ---
I wouldn't expect any *if libgcc function names to be used, because "tf"
libgcc names are supposed to refer to the ibm128 format and "kf" names are
supposed to refer to the IEEE binary128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2022-01-26
The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke. I think this was always fragile given the
possibility of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #7 from mikael at logicalclocks dot com ---
Oracle Linux bug:
https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=17755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Bug ID: 104255
Summary: parsing trailing return type fails with parameter pack
expansion when two parameter packs at present
Product: gcc
Version: 12.0
Status:
On Wed, 26 Jan 2022, Patrick Palka wrote:
> On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
> >
> > On 1/19/22 11:15, Patrick Palka wrote:
> > > Here we're emitting a bogus error during ahead of time evaluation of a
> > > non-dependent immediate member function call such as a.f(args)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #6 from mikael at logicalclocks dot com ---
Hi,
Gather I could send the same bug info to Oracle as well.
Regarding the -save-temps to the failing command it is
a bit difficult since I simply run make which has its
make files created
Hi!
On Thu, Dec 23, 2021 at 10:12:19AM +0800, Kewen.Lin wrote:
> PR target/103627
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
> hunk affecting VSX and ALTIVEC to the appropriate place.
>
> gcc/testsuite/ChangeLog:
>
> PR target/103627
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104254
Bug ID: 104254
Summary: -freport-bug should be mentioned on
https://gcc.gnu.org/bugs/
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #5 from Andrew Pinski ---
Also since this is a compiler provided by Oracle, you should report the failure
to them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #4 from Andrew Pinski ---
Read https://gcc.gnu.org/bugs/ .
The simple answer is add -save-temps to the comannd line which is failing and
that should give you a preprocessed source. The other option you could try is
-freport-bug and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #3 from mikael at logicalclocks dot com ---
Sorry, I am not an expert in GCC lingo, so plugin in the context
of GCC I don't know what it means. MySQL have lots of plugins, but
I assume this is not what you refer to.
Unfortunately I
On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
>
> On 1/19/22 11:15, Patrick Palka wrote:
> > Here we're emitting a bogus error during ahead of time evaluation of a
> > non-dependent immediate member function call such as a.f(args) because
> > the defacto templated form for such a call is
Hi all,
I won't be able to attend, as the IOMMU TG is convening in the same
timeslot tomorrow.
However, please be advised that (to my knowledge and after checking with
Stephano) the Zcea is on-hold and not frozen.
Thanks,
Philipp.
On Wed, 26 Jan 2022 at 14:05, wrote:
> Hi all,
>
> There is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Bug ID: 104253
Summary: libgcc missing __floatdiif
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Hi!
On Thu, Dec 23, 2021 at 10:09:27AM +0800, Kewen.Lin wrote:
> As PR103627 shows, there is an unexpected case where !TARGET_VSX
> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
> for MMA. By looking into the ICE, I noticed that the current
> MMA implementation depends on
On Wed, Jan 26, 2022 at 11:14:54PM +0100, Tobias Burnus wrote:
> ]I saw that the following now is implemented:
>
> * requires: dynamic_allocators is now also works
> (by assuming that it is supported, no longer giving 'sorry')
>
]I saw that the following now is implemented:
* requires: dynamic_allocators is now also works
(by assuming that it is supported, no longer giving 'sorry')
https://gcc.gnu.org/r12-6641-g450c85b81f4dd67bf6211d307afdc0f3c07ef44f
* in_reduction on target: Now also supported for Fortran
On Wed, 26 Jan 2022 at 22:08, Dimitar Dimitrov wrote:
>
> On Tue, Jan 25, 2022 at 09:09:51PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > Tested x86_64-linux, pushed to trunk. Backports to follow.
> >
> >
> > This adds a new internal flag to the filesystem::directory_iterator
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Francois-Xavier Coudert ---
> Pushed the fix as logical after checking on aarch64-apple-darwin.
>
On Tue, Jan 25, 2022 at 09:09:51PM +, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux, pushed to trunk. Backports to follow.
>
>
> This adds a new internal flag to the filesystem::directory_iterator
> constructor that makes it fail if the path is a symlink that resolves to
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 84787, which changed state.
Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
Bug 32770 depends on bug 84787, which changed state.
Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
--- Comment #6 from anlauf at gcc dot gnu.org ---
*** Bug 84787 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787
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=104252
--- Comment #2 from Andrew Pinski ---
Note the C/C++ front-end do support this though:
int main(void)
{
const int n = 3;
int a[n]={};
int i, j, s, t;
for (i = 0; i < n ; i++) {
t = 0;
#pragma omp parallel for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Felix Köhler from comment #0)
> > you cannot expect to get passed the accumulator value as the first argument
> > to BinOp and the sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104239
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fd5b0488ad5e4f29b65238e06a2d65b7de120235
commit r12-6885-gfd5b0488ad5e4f29b65238e06a2d65b7de120235
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104252
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-26
Keywords|
Hi!
On Wed, Jan 26, 2022 at 10:03:36PM +0100, Jakub Jelinek wrote:
> When writing testcases for the previously posted patch, I have noticed
> that 3 of the headers aren't valid C89 (I didn't have any dg-options
> so -ansi -pedantic-errors was implied and these errors were reported).
Hrm. Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251
--- Comment #3 from Jonathan Wakely ---
The non-parallel version of std::reduce really only exists for completeness,
because the parallel overload (the one taking an execution policy argument)
exists, and so a non-parallel one was added too.
On Wed, 26 Jan 2022, Joseph Myers wrote:
> fmin and fmax:
Also:
* If the arguments are +0 and -0 in some order, it's unspecified what sign
the result has.
> fminimum and fmaximum:
> fminimum_num and fmaximum_num:
Also:
* These four functions are required to treat -0 as less than +0.
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104252
Bug ID: 104252
Summary: OpenMP array reduction support issue
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104239
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2bf8da684b712a16c67f3defc0dd97f175f8f4ad
commit r12-6884-g2bf8da684b712a16c67f3defc0dd97f175f8f4ad
Author: Jakub Jelinek
Date:
Hi!
When writing testcases for the previously posted patch, I have noticed
that 3 of the headers aren't valid C89 (I didn't have any dg-options
so -ansi -pedantic-errors was implied and these errors were reported).
The following patch fixes those, ok for trunk?
Note, as can be seen even in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2022-January/057478.html
This fixes
gfortran.dg/team_change_1.f90
gfortran.dg/team_number_1.f90
gfortran.dg/popcnt_poppar_2.F90 (-m64, not supported
Dear Fortranners,
the use of -fdefault-integer-8 exhibits several cases where
we missed to convert the result of an intrinsic from the
declared to the effective resulting type.
The attached obvious patch fixes this for IMAGE_STATUS,
TEAM_NUMBER, and POPCNT/POPPAR.
OK for mainline if regtesting
On Wed, Jan 26, 2022 at 3:45 PM Jakub Jelinek wrote:
>
> Hi!
>
> r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
> to rs6000, these headers are on x86 standalone headers that various
> programs include directly rather than including them through
> .
> Unfortunately, for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104239
--- Comment #2 from Marc Glisse ---
Thanks for fixing that bug, but don't you still have issues with
NO_WARN_X86_INTRINSICS if you rely on __has_include for immintrin.h?
Hi!
r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
to rs6000, these headers are on x86 standalone headers that various
programs include directly rather than including them through
.
Unfortunately, for that change the bmiintrin.h and bmi2intrin.h
headers haven't been
On Wed, 26 Jan 2022, Joseph Myers wrote:
> fmin and fmax:
>
> * Treat quiet NaN as missing data and return the other argument (if a
> number).
>
> * Treat signaling NaN like most functions (raise invalid, return quiet
> NaN).
>
> fminimum and fmaximum:
>
> * Treat quiet NaN like most
As at r2.2 of the RISC-V ISA specification[1] the FMIN and FMAX machine
instructions fully match our requirement for the `fminM3' and `fmaxM3'
standard RTL patterns:
"For FMIN and FMAX, if at least one input is a signaling NaN, or if both
inputs are quiet NaNs, the result is the canonical NaN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251
--- Comment #1 from Andrew Pinski ---
(In reply to Felix Köhler from comment #0)
> According to cppreference.com:
> "The behavior is non-deterministic if binary_op is not associative or not
> commutative. ... in other words, reduce behaves like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251
Bug ID: 104251
Summary: std::reduce scrambles argument order for BinaryOp
function call: Possible bug?
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
On Wed, 26 Jan 2022, Maciej W. Rozycki wrote:
> > The newer instruction semantics correspond to the functions fminimum_num
> > and fmaximum_num, not fminimum and fmaximum (which are functions that
> > treat both quiet and signaling NaNs like most libm functions do - any
> > argument a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104238
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104206
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9bf217920457f2e2d46b601f24721780a20a031b
commit r12-6883-g9bf217920457f2e2d46b601f24721780a20a031b
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104206
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9bf217920457f2e2d46b601f24721780a20a031b
commit r12-6883-g9bf217920457f2e2d46b601f24721780a20a031b
Author: Jason Merrill
Date:
My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104206
PR c++/101072
gcc/cp/ChangeLog:
* semantics.cc (finish_compound_literal): Restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104241
Andrew Pinski changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104238
--- Comment #5 from Jakub Jelinek ---
binutils 2.35 readelf doesn't warn either, and neither 2.37.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104241
--- Comment #4 from Jakub Jelinek ---
Didn't r12-6877-g8bcf835e0a4e3334e1c60f314ae6917ba648bdde fix this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104241
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104241
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104249
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104242
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104242
--- Comment #2 from Andrew Pinski ---
Note Clang's error message might be more helpfull:
In file included from :2:
In file included from
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/any:39:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #6 from Jason Merrill ---
(In reply to Jason Merrill from comment #5)
> It is surprising that we warn with a user-provided copy constructor and
> don't with a defaulted constructor. It changes the code a bit because it
> means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
--- Comment #2 from Andrew Pinski ---
Also please read the error message too:
// *** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins
// Please submit a full bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104244
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104033
--- Comment #5 from Andrew Pinski ---
>From Jakub in the other bug report:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587856.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588689.html
I need to rewrite the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #7 from Jakub Jelinek ---
A temporary workaround now applied.
The dwarf-discuss thread seems to prefer using separate DW_ATE_* values instead
of DW_AT_precision/DW_AT_minimum_exponent, but hasn't converged yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104033
Andrew Pinski changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104246
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104033
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104226
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:866d73019bd4d1804f7e09409322e6605b81780b
commit r12-6882-g866d73019bd4d1804f7e09409322e6605b81780b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104226
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:abea1c9a252ef7712ab800360e1e0e2697ee14f2
commit r12-6881-gabea1c9a252ef7712ab800360e1e0e2697ee14f2
Author: Jakub Jelinek
Date:
On Wed, 26 Jan 2022, YunQiang Su wrote:
> Since MIPS r2, the IPL section in Cause register has been expand
> to 8bit instead of 6bit.
Hmm, I cannot see it in my copy of the architecture manual I'm afraid.
The interpretation may have changed, but the field is still 6-bit (not
counting the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104245
--- Comment #4 from Andrew Pinski ---
Well I can't reproduce it with the following cmake options:
cmake -DABSL_USE_EXTERNAL_GOOGLETEST=ON -DBUILD_TESTING=off
make
Also cmake projects are a pain to work with really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104250
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104246
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #5 from Jason Merrill ---
(In reply to Sergei Trofimovich from comment #0)
> input_files.emplace_back(Z{
> arg.str(), // what is the lifetime of this temporary?
This prvalue initializes the 'name' member of the Z temporary,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104246
Andrew Pinski changed:
What|Removed |Added
Host|hppa*-*-* |
Build|hppa*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104250
Bug ID: 104250
Summary: [i386] GCC may want to use 32-bit (I)DIV if it can for
64-bit operands
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:c3251374af4b82888b6be3eb9cfa6b0b3944907b
commit r11-9516-gc3251374af4b82888b6be3eb9cfa6b0b3944907b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the following simple patch resolved the issue:
diff --git a/gcc/function.cc b/gcc/function.cc
index e1d2565f8d9..c8a77c9a624 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -5942,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104249
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #2 from qinzhao at gcc dot gnu.org ---
This is a bug in pass_zero_call_used_regs, when updating df after the zeroing
sequence is added in the epilogue of the function, we should call
"df_update_exit_block_uses" to update the reg use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:200afb44967520c1c75a35f91c4a56b5e5fb65ff
commit r9-9928-g200afb44967520c1c75a35f91c4a56b5e5fb65ff
Author: Harald Anlauf
Hi!
On Wed, Jan 26, 2022 at 10:26:45AM +0800, Kewen.Lin wrote:
> on 2022/1/14 上午12:31, David Edelsohn wrote:
> Yeah, but IMHO it still can confuse new comers at first glance.
Yes, or at least cause to read (well, grep) the whole backend and
scratch heads.
> >> 2) Bootstrapped and tested one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0646ff3e170b87050bad4448b89406e476f64496
commit r10-10421-g0646ff3e170b87050bad4448b89406e476f64496
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95485
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
1 - 100 of 256 matches
Mail list logo
