https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
--- Comment #2 from Richard Biener ---
Testcase that also triggers on x86_64 and without graphite:
double foo (double x, int n)
{
double s = 0.;
for (int i = 0; i < n; ++i)
{
s += x;
s += x;
s += x;
}
return s;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95900
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95900
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #2 from Markus F.X.J. Oberhumer ---
Somewhat related: the same code compiled with arm64-gcc -mabi=ilp32 -frwapv
does miscompile *both* functions.
See https://gcc.godbolt.org/z/uxDAtx
Should I open a new issue for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #3 from Jakub Jelinek ---
For ilp32 I'm not convinced it is a bug, the address space needs to be 32-bit
only and for this to cause problems, you need a 4GB+ element array with the
pointer pointing into the middle of it such that both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #4 from Markus F.X.J. Oberhumer ---
Yes, ilp32 might be a corner case.
Still, clang-10 does create the expected code.
See https://gcc.godbolt.org/z/aEokbX for
clang-10 -target arm64_32-ios -O2 -fomit-frame-pointer -fwrapv
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
Paul Hua changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #5 from Jakub Jelinek ---
Created attachment 48788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48788&action=edit
gcc11-pr95903.patch
Untested fix. I don't really care what clang generates or what you find
expected on ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #1 from Jonathan Wakely ---
This is a well-known issue where diagnostics in function parameter-lists all
have the location of the closing brace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Jonathan Wakely changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
--- Comment #4 from Jonathan Wakely ---
PR 95892 points out the -Wsign-conversion warnings below all have the location
of the closing parenthesis:
unsigned int var = 10;
void foo (
int a = var,
int b = var,
int c = var )
{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #3 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #1)
> This is a well-known issue where diagnostics in function parameter-lists all
> have the location of the closing brace.
Thank you, Jonathan.
I guess bug 95831 has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809
--- Comment #3 from Haoxin Tu ---
(In reply to Nathan Sidwell from comment #2)
> yup, dr2061 made that ill-formed.
>
> p1701 (wg21.link/p1701) documents the behaviour and it appears EWG is
> exploring another avenue to resolve the underlying p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #6 from Markus F.X.J. Oberhumer ---
Thanks for the quick fix!
And no need to be grumpy, I'm just trying to nail down those pesky edge
cases...
As for ILP32, here is another suspicious test case, now only using just a
little bit more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-06-26
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Bug ID: 95907
Summary: ICE in unrecognizable insn
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #7 from Jakub Jelinek ---
I believe all arrays larger than half of the address space are outside of the
standard already, one can't perform e.g. address arithmetics on those because
it overflows the ptrdiff_t in which it is evaluated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5b959c22bc0158faa359a5899bf46e815dc65290
commit r11-1671-g5b959c22bc0158faa359a5899bf46e815dc65290
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #6 from Martin Liška ---
Thanks for reduction, I can confirm that. What happens:
mips-ps-5.c.171t.loopdone:
_34 = vect__1.7_28 == vect__3.11_33;
vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
which is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #8 from Markus F.X.J. Oberhumer ---
Got it, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #7 from rguenther at suse dot de ---
On Fri, 26 Jun 2020, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
>
> --- Comment #6 from Martin Liška ---
> Thanks for reduction, I can confirm that. Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #8 from Richard Biener ---
Possibly simply a disconnect in the mips expanders for vcond vs vcmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908
Bug ID: 95908
Summary: [AArch64] wrong code with ILP32 and -fwrapv
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #9 from Markus F.X.J. Oberhumer ---
[ Just for reference, created bug 95908 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:e74c76073092f4715007584edb1fe6b7a17274db
commit r11-1673-ge74c76073092f4715007584edb1fe6b7a17274db
Author: Iain Sandoe
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
Richard Biener changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95068
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95388
Richard Biener changed:
What|Removed |Added
Known to fail||11.0
Summary|[Regression 10/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.2
Keywords|rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95909
Bug ID: 95909
Summary: Wrong line information at Og
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910
Bug ID: 95910
Summary: transform view in combination with single view calls
const qualified begin even if it is not const
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911
Bug ID: 95911
Summary: [8/9/10/11] returning && makes an error without any
warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
--- Comment #3 from Michael Bruck ---
Some of the abort messages in main were not updated after copy/paste
"Failed to call one of the ... cases"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
--- Comment #4 from Iain Sandoe ---
(In reply to Michael Bruck from comment #3)
> Some of the abort messages in main were not updated after copy/paste
> "Failed to call one of the ... cases"
I made individual test-cases for each promise entry, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809
--- Comment #4 from Nathan Sidwell ---
The code is invalid due to DR2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Michael Bruck from comment #3)
> > Some of the abort messages in main were not updated after copy/paste
> > "Failed to call one of the ... cases"
>
> I
gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95831
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
--- Comment #5 from Jonathan Wakely ---
*** Bug 95831 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #4 from Jonathan Wakely ---
Yes, thanks, I've closed that one as a duplicate too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:95f5dc7f70b09def9f2002f5cbef986b21d456e3
commit r10-8373-g95f5dc7f70b09def9f2002f5cbef986b21d456e3
Author: Iain Buclaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:3e1af1d0be13e4615e001fb19e294c8d28d69f94
commit r10-8372-g3e1af1d0be13e4615e001fb19e294c8d28d69f94
Author: Iain Buclaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
Jonathan Wakely changed:
What|Removed |Added
CC||570070308 at qq dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95912
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
Jakub Jelinek changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment #19 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250
--- Comment #4 from CVS Commits ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:57096f5c52be8c5f0c29663234f31845bb172216
commit r9-8701-g57096f5c52be8c5f0c29663234f31845bb172216
Author: Iain Buclaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:53bc489468c3bf2958151ba624679cadff403ce8
commit r9-8700-g53bc489468c3bf2958151ba624679cadff403ce8
Author: Iain Buclaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #17 from Jonathan Wakely ---
95911 boils down to this:
#include
struct X { int i = 0; };
X&& f(X&& x) { return std::move(x); }
int main()
{
X&& x = f(X{});
return x.i;
}
With recent releases we get a -Wuninitialized warning,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911
--- Comment #2 from Jonathan Wakely ---
As I noted in Bug 49974 comment 17, if you actually try to us the variable
after it's been destroyed then GCC *does* warn. And if you use
-fsanitize=address then you get an error at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
--- Comment #1 from Segher Boessenkool ---
Confirmed (in C, with _Bool).
This is yet another case of enabling some insns but disabling many other
insns: our power10 support requires insns we enable on power9 and later
only (set[n]bc[r] is a spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95913
Bug ID: 95913
Summary: Capturing lambdas inlining behavior changed in GCC
10.x
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95914
Bug ID: 95914
Summary: Failure to optimize saturated add properly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #5 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #4)
> Yes, thanks, I've closed that one as a duplicate too.
Ok, you are so welcome.
By the way, could you please check other diagnostic issues (bug95871, bug95872,
bug9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
Bug ID: 95915
Summary: std::variant doesn't like types with a defaulted
virtual destructor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
Ville Voutilainen changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82953
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86353
Sergei Trofimovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95030
--- Comment #1 from Mingye Wang ---
Thanks to tcl_de in sourceware bz[1], a CPUID dump from eden-x4 is available:
http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls6FE_CNR_Isaiah_CPUID.txt
MOVBE, POPCNT, AES, PCLMUL, FSGSBASE, RDRND, B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553
--- Comment #6 from Marek Polacek ---
I think it would make sense to detect this too:
struct E { };
template concept E = false;
template concept F = false;
struct F { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95913
--- Comment #1 from Andrew Pinski ---
Most likely a heurstic changes caused this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95916
Bug ID: 95916
Summary: ICE during GIMPLE pass: slp : verify_ssa failed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95916
--- Comment #1 from Vsevolod Livinskiy ---
This bug might be related to bug 95761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
Jonathan Wakely changed:
What|Removed |Added
Summary|std::variant doesn't like |[10/11 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Bug ID: 95917
Summary: coroutine functions leak under freestanding mode
causing dependencies and binary bloat.
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #1 from fdlbxtqi ---
void __dummy_resume_destroy() __attribute__((__weak__));
void __dummy_resume_destroy() {}
struct __noop_coro_frame
{
void (*__r)() = __dummy_resume_destroy;
void (*__d)() = __dummy_resume_destroy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #2 from fdlbxtqi ---
This makes me mad.
I compiled this under freestanding mode. Now coroutine causes binary bloat
which is completely unacceptable for me.
The problem of C++ is that you have to always write inline to undo the brain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #3 from fdlbxtqi ---
Jonathan. I am MAD at you. This is absolutely your fault. I told you to always
write inline and you guys do not then allow Herb Sutter to ban me. Here is the
fault in your own controlled codebase. Are you satisfie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #4 from Iain Sandoe ---
(In reply to fdlbxtqi from comment #3)
> Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> always write inline and you guys do not then allow Herb Sutter to ban me.
> Here is the fault i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #5 from fdlbxtqi ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:5e00a2d1aa68f92e413fec01ce912401bcfcf44f
commit r10-8374-g5e00a2d1aa68f92e413fec01ce912401bcfcf44f
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95826
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:32613b6af830f12ee5b6ef97edd782666f47cbb8
commit r10-8375-g32613b6af830f12ee5b6ef97edd782666f47cbb8
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #6 from fdlbxtqi ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
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=95910
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863
H.J. Lu changed:
What|Removed |Added
CC||craig.topper at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
Bug ID: 95918
Summary: gfortran.dg/char4-subscript.f90 fails for BE
architectures
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
[Please keep me in CC as I'm not subscribed to this mailing list]
Hello,
I recently implemented an external process management tool and cannot get
coverage report of the code that runs right before execve after calling fork.
It is specified in the GCC doc that it should work given gnu++11 flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95919
Bug ID: 95919
Summary: new test base gfortran.dg/char4-subscript.f90 in
r11-1654 fails on BE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #1 from Marc Glisse ---
I'd say generate a (vec_)cond_expr, not directly a max. That is, replace the
comparison with any truth_valued_p (hmm, that function probably stopped working
for vectors when all comparisons were wrapped in vec_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863
H.J. Lu changed:
What|Removed |Added
CC||polacek at redhat dot com,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95920
Bug ID: 95920
Summary: Implicit declaration of function 'feenableexcept' in
fpu-target.h
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863
--- Comment #3 from H.J. Lu ---
Created attachment 48790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48790&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
--- Comment #3 from Vladimir Makarov ---
I looked at this problem.
All assignments are done in IRA (LRA does not change them). We can not make a
better assignment because scratches do not permit to store any preferences from
instruction constra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
Bug ID: 95921
Summary: [m68k] invalid codegen for __builtin_sqrt
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #1 from Rich Felker ---
I wonder if the fact that GCC thinks the output of the insn is already double
suggests other similar bugs in the m68k backend, though... If extended
precision were working correctly, I'd think it would at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655
--- Comment #4 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:727efd27da90fe09ed393c7bb44bba071ae0e0d3
commit r11-1680-g727efd27da90fe09ed393c7bb44bba071ae0e0d3
Author: H.J. Lu
Date: Fri Jun 12 05:
1 - 100 of 125 matches
Mail list logo
