https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
--- Comment #2 from Stephan Bergmann ---
(In reply to Richard Biener from comment #1)
> Does it work placing the initial part of the function in a separate { }?
Yes,
> @@ -14,11 +14,13 @@
> return true;
> }
> void f3() {
> +{
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|riscv64-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Richard Biener changed:
What|Removed |Added
Blocks||93385
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112
--- Comment #1 from Richard Biener ---
Try -fcf-protection=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
Richard Biener changed:
What|Removed |Added
Version|unknown |10.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #5 from Aurelien Jarno ---
(In reply to Jim Wilson from comment #3)
> Newlib incidentally uses (x-x)/(x-x) where x is the input value, so there
> are no constants involved, and the divide does not get optimized away. This
> still wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #19)
> There's some stuff above this in the module but this is the part that shows
> the error and I think it contains all the declarations.
>
> subroutine Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496
--- Comment #2 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #1)
> We are close to making 'in' mean 'scope const', it is already available as a
> preview in dmd 2.092: https://dlang.org/changelog/2.092.0.html#preview-in
Indeed, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #4 from Marc Glisse ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits. If I write (4.0 / 3.0) for insta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
Bug ID: 95122
Summary: Cross-compile arm32 toolchain with hard float, but
Error in gcc final
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #5 from Andrew Pinski ---
(In reply to Joseph C. Sible from comment #3)
> Also, is that documented to work that way anywhere? I didn't notice anything
> in the manual to that effect.
Register names seems not to be documented, correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #4 from Andrew Pinski ---
(In reply to Joseph C. Sible from comment #2)
> Does this mean that Clang is wrong, then? Because it works the way I
> wanted/expected.
Depends, this is a GNU extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #3 from Joseph C. Sible ---
Also, is that documented to work that way anywhere? I didn't notice anything in
the manual to that effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #2 from Joseph C. Sible ---
Does this mean that Clang is wrong, then? Because it works the way I
wanted/expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
Bug ID: 95121
Summary: Wrong code generated: low-byte registers are silently
used in place of their corresponding high-byte
registers (ah, bh, ch, dh)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
--- Comment #2 from Witold Baryluk ---
Created attachment 48530
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48530&action=edit
Minimized example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
--- Comment #1 from Witold Baryluk ---
Further minimized:
==
import std.stdio;
import std.algorithm.comparison : min;
int main() {
return std.algorithm.comparison.min(3, 2);
}
==
Removing `import std.stdio;`, results in the same err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #4 from Adrien Dessemond ---
The hang also happens with "-O2 -ftree-vectorize -fopt-info-vec"
I confirm that removing "-fopt-info-vec" avoids the hang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
Bug ID: 95120
Summary: [D] Incorrectly allows fqdn access to imported symbols
when doing selective imports.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496
Witold Baryluk changed:
What|Removed |Added
CC||witold.baryluk+gcc at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #1 from Bill Long ---
Appears to be a regression.
The original submitter thinks it is hanging in __lll_lock_wait inside CLOSE.
Th same hang can be observed if the references to omp_get_num_threads are
removed, but you still compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Bug ID: 95119
Summary: CLOSE hangs when -fopenmp is specified in compilation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #19 from Bill Seurer ---
There's some stuff above this in the module but this is the part that shows the
error and I think it contains all the declarations.
subroutine Z()
real(r8) :: cld(99,99)
real(r8) cldeps
parameter (cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #2 from Sergei Trofimovich ---
Seems to be a regression since gcc-9.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #1 from Sergei Trofimovich ---
Created attachment 48528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48528&action=edit
bug.c
t-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 compression algorithms: zlib zstd
gcc version 11.0.0 20200513 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #18 from Bill Seurer ---
I am still cutting down the code but this should answer the question about if
it really could be zero:
if (cldeps > 0) then
do k = k1,k2
asor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
Luke Robison changed:
What|Removed |Added
CC||robison at arlut dot utexas.edu
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #2 from Marc Glisse ---
Or during CCP with the simpler
double f(){
double d=__builtin_inf();
return d/d;
}
and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #1 from Marc Glisse ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79706
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79706
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4924293a62ee797310dd448e545118afd5aebb3f
commit r11-373-g4924293a62ee797310dd448e545118afd5aebb3f
Author: Patrick Palka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95117
Bug ID: 95117
Summary: Segmentation fault with static await_ready() or
await_resume()
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95020
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7e52f8b1e03776575b92574252d9b6bbed9f1af4
commit r11-372-g7e52f8b1e03776575b92574252d9b6bbed9f1af4
Author: Patrick Palka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
--- Comment #2 from Owen Smith ---
Ah ok thanks, I didn't know about P0634R3 :D.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95066
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:661232da72d29f8f2385d5f588727beb74360144
commit r11-371-g661232da72d29f8f2385d5f588727beb74360144
Author: Marek Polacek
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #10 from Avi Kivity ---
Well, the standard is useless here.
In
[foo] () -> lazy { co_return foo; } ()
a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #7 from Avi Kivity ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #8 from Avi Kivity ---
Created attachment 48526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526&action=edit
less lame testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Bug ID: 95116
Summary: [C++ 20] Accepts invalid code with decltype dependent
type
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Bug ID: 95115
Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #6 from Iain Sandoe ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
>
> If the coroutine is a non-static member function, such as task
> my_class::method1(int x) const;, its Promise type is
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #5 from Avi Kivity ---
This snippet from cppreference:
If the coroutine is a non-static member function, such as task
my_class::method1(int x) const;, its Promise type is
std::coroutine_traits, const my_class&, int>::promise_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #4 from Iain Sandoe ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #3 from Avi Kivity ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #2 from Avi Kivity ---
Created attachment 48524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524&action=edit
lame testcase
Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #1 from Iain Sandoe ---
There are some gotchas with coroutines and references (both regular and
rvalue).
* there could still be a bug here, so I want to double-check.
Please could you expand your snippets of code into a small test-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Mileston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
Bug ID: 95114
Summary: [9/10/11 Regression] ICE in obj_type_ref_class for
structural-equality types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94024
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
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=95061
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #4 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:0d5d880994660e231f82b7cb1dcfab744158f7e0
commit r11-364-g0d5d880994660e231f82b7cb1dcfab744158f7e0
Author: Ian Lance Taylor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
--- Comment #3 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #2)
> Guess dup of the other PR where the IPA opts assume DCE which doesn't really
> happen (the *p load result is never used).
Indeed, -fno-ipa-sra fixes it. So, a d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jared changed:
What|Removed |Added
CC||jared.martinsen at fiserv dot
com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Bug ID: 95113
Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112
Bug ID: 95112
Summary: i386 procedures have prolog endbr32
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Bug ID: 95111
Summary: coroutines use-after-free with lambdas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #3 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:702adbb2fff0cc043f9c4e1af890421cb238cd18
commit r11-362-g702adbb2fff0cc043f9c4e1af890421cb238cd18
Author: Ian Lance Taylor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:287552950d56be47adb6b6bf2eae2d612233eaec
commit r11-361-g287552950d56be47adb6b6bf2eae2d612233eaec
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #1 from Tobias Burnus ---
Confirmed – see PR 94690 comment 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
Bug ID: 95110
Summary: new test case in r11-345 error:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #10 from Tobias Burnus ---
Created attachment 48522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522&action=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')
The patch solves an independent iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
Bug ID: 95109
Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90
after r11-349
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #3)
> A comment from the original user: gfortran 8.3.0 appears to do the right
> thing. So perhaps a regression somewhere in the 9.x line?
A note of the gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Bug ID: 95108
Summary: [10/11 Regression] ICE in tree_fits_uhwi_p, at
tree.c:7292
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107
Bug ID: 95107
Summary: [10/11 Regression] ICE in hash_operand, at
fold-const.c:3768
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106
Bug ID: 95106
Summary: Bogus warning from module with long name and an
equivalence
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #3 from Bill Long ---
A comment from the original user: gfortran 8.3.0 appears to do the right
thing. So perhaps a regression somewhere in the 9.x line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #17 from Bill Seurer ---
he patch works and has no further fallout that I see.
I will still try to extract something small from that big fortran function but
as I have not written any fortran code in more than 35 years it may take a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #11 from pskocik at gmail dot com ---
Thanks for the shot at a fix, Richard Biener.
Since I have reported this, I think I should mentioned a related suboptimality
that should probably be getting fixed alongside with this (if this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94983
--- Comment #3 from Andrey Vihrov ---
Another sample, probably caused by the same underlying issue:
struct T
{
char a[3];
};
void bar()
{
T t{"x"}; // OK
T{"x"}; // OK
new T{"x"}; // err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #17 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Richard Biener ---
[...]
> Hmm, OK looks like memcpy is not folded, likely because the source is
> not known to be appropriately aligned.
[...]
> should fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
Bug ID: 95105
Summary: Bogus reference-compatibility error for
arm_sve_vector_bits
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
P
1 - 100 of 146 matches
Mail list logo