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=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=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=79706
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=81827
Luke Robison changed:
What|Removed |Added
CC||robison at arlut dot utexas.edu
--- Comme
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
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=95118
--- Comment #1 from Sergei Trofimovich ---
Created attachment 48528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48528&action=edit
bug.c
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=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=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=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=95118
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comm
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=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=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
--- 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=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=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=95121
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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 #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 #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=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=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
--- 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=95119
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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=95103
Richard Biener changed:
What|Removed |Added
Version|unknown |10.1.0
Keywords|
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=95112
--- Comment #1 from Richard Biener ---
Try -fcf-protection=none
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=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=95115
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|riscv64-u
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=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=95118
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
101 - 146 of 146 matches
Mail list logo
