https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #11 from Tobias Burnus ---
(In reply to David Binderman from comment #10)
> Reduced C code: [...]
> $ /home/dcb/gcc/results/bin/gcc -c -w -O3 -march=bdver2 bug716.c
Compiles here without an ICE.
Additionally, are you sure that tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #15 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #14)
> (In reply to Hongtao.liu from comment #12)
> > (In reply to Jakub Jelinek from comment #10)
> > > Last touched in PR99563.
> > > I guess for the explicit user vzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
Bug ID: 100444
Summary: std::random_device isn't random on AMD
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
Iru Cai changed:
What|Removed |Added
CC||mytbk920423 at gmail dot com
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #1 from Richard Biener ---
Isn't this worked around at kernel level by disabling RDRAND support on
affected CPUs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
Richard Biener changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #19 from Alex Coplan ---
Ah, I missed that Srinath had already requested a backport here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #3 from Jakub Jelinek ---
The _serialize intrinsic is a standard Intel intrinsic:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_serialize&expand=4902
and any intrinsic can be implemented as an inline function, m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b5254d6b75fe6be669396cd1261f1cba829cc451
commit r12-558-gb5254d6b75fe6be669396cd1261f1cba829cc451
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #8 from Iain Sandoe ---
(In reply to Richard Biener from comment #7)
> (In reply to Iru Cai from comment #6)
> > I've checked host_detect_local_cpu() in gcc/config/i386/driver-i386.c. GCC
> > detects x86 host CPU micro architecture b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ad96c867e173c1ebcfc201b201adac5095683a08
commit r12-559-gad96c867e173c1ebcfc201b201adac5095683a08
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #9 from Jakub Jelinek ---
You could as well step through the driver-i386.c and cpuinfo.h code in the
debugger.
>From the info you've provided, seems you have __cpu_family 6 and __cpu_model
0x9e, so get_intel_cpu should reach:
cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #2 from Edward Cree ---
(In reply to Richard Biener from comment #1)
> Isn't this worked around at kernel level by disabling RDRAND support on
> affected CPUs?
Not sure. I wondered if it might be, so I straced the process and it di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #4 from Richard Biener ---
So at least libstdc++ does check RDRAND availability via cpuid. It also
already
checks the return value for "no avaialble randomness":
while (__builtin_ia32_rdrand32_step(&val) == 0)
if (--r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> does the intrinsic
> header leak in via a C++ standard include?
No, not as far as I know. A testcase is definitely needed to demonstrate the
reported problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> The __rvalue_ostream_type constraints are going away soon:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566863.html
N.B. that change is on gcc trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355
--- Comment #4 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:e82e87a851cdea9f4f43f342842025b068287d4e
commit r12-561-ge82e87a851cdea9f4f43f342842025b068287d4e
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
--- Comment #2 from Andres Freund ---
Created attachment 50763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50763&action=edit
preprocessed reproducer
Huh, sorry for that. I thought I had attached it. When I tried again now it
failed due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #1 from Jonathan Wakely ---
(In reply to gnzlbg from comment #0)
> A member using declaration brings into the derived class all the overloads
> of the specified function from the given base class, except for any
> overloads where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:
https://gcc.gnu.org/g:f1370bf2aa6cac4ab6235d8480b0a5d4f85ca54e
commit r10-9806-gf1370bf2aa6cac4ab6235d8480b0a5d4f85ca54e
Author: Srinath P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:
https://gcc.gnu.org/g:d218fed53d811212b015a08cd2e1214000813fbf
commit r10-9807-gd218fed53d811212b015a08cd2e1214000813fbf
Author: Andre Vie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #2 from Jonathan Wakely ---
C++11 7.3.3 [namespace.udecl] p15:
"When a using-declarator brings declarations from a base class into a derived
class scope, member functions and member function templates in the derived
class override a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #5 from Jonathan Wakely ---
(In reply to Richard Biener from comment #4)
> Thus I believe the issue is mitigated at the kernel level and people that
Yes, that's my understanding.
> cannot be bothered to update their ucode or the ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #6 from Jonathan Wakely ---
(In reply to Richard Biener from comment #4)
> so here it could check for -1 as well though in theory that
> can happen with true randomness as well, even if very unlikely. Note
> that it would never retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #12 from David Binderman ---
It looks like my ice is due to commit f3661f2d63fbc5fd30c24d22137691e16b0a0a17
by Uroš Bizjak.
I'll send in another bug report. Sorry for this mixup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
--- Comment #5 from Jakub Jelinek ---
My patch was an optimization, certainly not an attempt to fix any bugs.
So I bet the bug is now latent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
Bug ID: 100445
Summary: ice during RTL pass: vregs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Bug ID: 100446
Summary: GDB has problems reading GCC's debugging info level
-g3
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #6 from heinzisoft at web dot de ---
Seems the crypto++ library includes x86intrin.h, and that leaks the macro. I
assume a library isn't supposed to do that?
https://github.com/weidai11/cryptopp/blob/master/misc.h#L83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #7 from Jakub Jelinek ---
That is a decision of each library what headers it includes and what
identifiers it reserves. Just change your source...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #13 from Andrew Stubbs ---
I found a lot more ICEs when testing my patch. They look to be unrelated
(TImode come back to haunt us), but it makes it hard to be sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #7 from Edward Cree ---
(In reply to Richard Biener from comment #4)
> people that
> cannot be bothered to update their ucode or the kernel are not likely
> bothered to update libstdc++ either.
Fwiw, my kernel is fairly up-to-date (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #14 from Jakub Jelinek ---
This PR is about amdgcn ICEs, so please move x86 related ICEs to a different
PR, they have nothing to do with this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #15 from David Binderman ---
(In reply to Jakub Jelinek from comment #14)
> This PR is about amdgcn ICEs, so please move x86 related ICEs to a different
> PR, they have nothing to do with this bug.
Done. Please see # 100445.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Richard Biener changed:
What|Removed |Added
Component|other |debug
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #10 from Iain Sandoe ---
build of 11.1 on macOS11 with no patches and default options
$ ./gcc/xgcc -Bgcc /source/test/general/empty-main.c -S -fverbose-asm
head -5 empty-main.s
# GNU C17 (GCC) version 11.1.0 (x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #8 from Jonathan Wakely ---
g:b0c0d878a8b5bf39dbea4c192fed26d340524439 enabled RDRAND and RDSEED for AMD
chips, where previously we'd only used RDRAND and only for Intel (which caused
one particular idiot to complain that we "hate AM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #3 from gnzlbg ---
http://eel.is/c++draft/namespace.udecl#11
> The set of declarations named by a using-declarator that inhabits a class C
> does not include member functions and member function templates of a base
> class that co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #2 from Richard Biener ---
Oh, and just to ask - did you try if lldb behaves "well" here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #9 from Richard Biener ---
Note that if you read the errata you figure that the broken RDRAND behavior can
occur after a suspend/resume cycle only which means that detecting this in
the RDRAND detection logic is too "early" if you ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #4 from Jonathan Wakely ---
That wording was only added to the draft in November, I don't think any
compilers implement all the P1787R6 changes yet.
There is still no mention of signatures, which is why I wondered why you're
talking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100447
Bug ID: 100447
Summary: gcc-9 -c -gsplit-dwarf -gdwarf-5 ICEs on an empty file
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #10 from Jonathan Wakely ---
Maybe we should go back to only using RDRAND for Intel :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #3 from R. Diez ---
Regarding "shifting the blame", no worries, I am grateful for any help.
I suspect that there is more than 1 issue here. Could you take a look at the
following aspect mentioned in the GDB bug?
8<8<
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100448
Bug ID: 100448
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #4 from Richard Biener ---
(In reply to R. Diez from comment #3)
> Regarding "shifting the blame", no worries, I am grateful for any help.
>
> I suspect that there is more than 1 issue here. Could you take a look at the
> following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:ccba1513d34cb1ad087a392621dbb5e0755bcab2
commit r11-8361-gccba1513d34cb1ad087a392621dbb5e0755bcab2
Author: Roman Zhuykov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:ccba1513d34cb1ad087a392621dbb5e0755bcab2
commit r11-8361-gccba1513d34cb1ad087a392621dbb5e0755bcab2
Author: Roman Zhuykov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100447
Richard Biener changed:
What|Removed |Added
Component|other |debug
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439
--- Comment #2 from Florin Iucha ---
This is for regular x86-64; we're using a cross-compiler sysroot to avoid
dependency on system libraries and be able to run the binary on different Linux
distributions.
I can't reproduce the problem on a "he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:9c4797e2b5dea101b28826dee8c30125764811e3
commit r10-9808-g9c4797e2b5dea101b28826dee8c30125764811e3
Author: Roman Zhuykov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:9c4797e2b5dea101b28826dee8c30125764811e3
commit r10-9808-g9c4797e2b5dea101b28826dee8c30125764811e3
Author: Roman Zhuykov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100448
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:702e2995f871becf8c1dbd352a8013d672fe4ad1
commit r9-9517-g702e2995f871becf8c1dbd352a8013d672fe4ad1
Author: Roman Zhuykov
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:702e2995f871becf8c1dbd352a8013d672fe4ad1
commit r9-9517-g702e2995f871becf8c1dbd352a8013d672fe4ad1
Author: Roman Zhuykov
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:a324c13210c321057b238bac94605fa1f8278d09
commit r8-10954-ga324c13210c321057b238bac94605fa1f8278d09
Author: Roman Zhuykov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84878
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Roman Zhuykov
:
https://gcc.gnu.org/g:a324c13210c321057b238bac94605fa1f8278d09
commit r8-10954-ga324c13210c321057b238bac94605fa1f8278d09
Author: Roman Zhuykov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100447
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Roman Zhuykov changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> template
> struct __is_insertable<_Ostream, _Tp,
> void_t()
><< declval())>>
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #2 from Jakub Jelinek ---
Sorry, r12-514-gf3661f2d63fbc5fd30c24d22137691e16b0a0a17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #11 from Iain Sandoe ---
I also tried on a xeon w machine with darwin19 (macOS 10.15), where it detects
skylake-avx512 (which is a reasonable description, although possibly
cascadelake would be slightly more accurate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #5 from R. Diez ---
In a nutshell: "objdump --syms" does not show that symbol, probably because the
routine was inlined, but "readelf --debug-dump" does show it.
Thanks for your help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #12 from Erik Schnetter ---
Yes, GCC 10.3 (built via MacPorts) still works. The sample program reports a
Skylake CPU with both compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #5 from gnzlbg ---
> There is still no mention of signatures, which is why I wondered why you're
> talking about them.
Re-reading that part, you are correct that it does not mention signatures. I
misunderstood it.
Reading [basic.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100449
Bug ID: 100449
Summary: Unrolled loop ignores __building_constant_p
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #3 from Jakub Jelinek ---
Slightly more readable testcase without warnings, -O3 -mxop:
int a, b[3];
void bar (int *);
void
foo (void)
{
for (; a < 3; a++)
b[a] = (a - 1) / 2;
bar (b);
}
IMHO we can either avoid the TARGET_X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #13 from Erik Schnetter ---
The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
debug output, I see that Spack inserts a "-march=skylake" command line option.
(I was not aware of this before.) It does so by cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #5 from Uroš Bizjak ---
ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is
needed:
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 347295afbb5..667dd057e0d 100644
--- a/gcc/config/i386/mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is
> needed:
Ah, you beat me by the second ;)
Anyway, I have no XOP target, so probably y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e99763ee6da8e378073b847243d9ac2538903534
commit r11-8363-ge99763ee6da8e378073b847243d9ac2538903534
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80675
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:ca7d2f2ec9142995179a5d832a946b50de05e659
commit r11-8369-gca7d2f2ec9142995179a5d832a946b50de05e659
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Jonathan Wakely from comment #4)
> > The __rvalue_ostream_type constraints are going away soon:
> > https://gcc.gnu.org/pipermail/gcc-patches/20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #7 from Jakub Jelinek ---
I have no XOP CPU either, normally I bootstrap on Intel i9-7960X and on my
desktop I have AMD Ryzen 5 3600, but that doesn't have XOP either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
Bug ID: 100450
Summary: Missing ' ' space for '-E' preprocessing output, works
with direct compilation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #14 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #13)
> The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
> debug output, I see that Spack inserts a "-march=skylake" command line
> option. (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91400
H.J. Lu changed:
What|Removed |Added
Version|unknown |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691
--- Comment #2 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:a2c593009fef1564dbef2237ee71e9fd08f5361e
commit r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e
Author: Paul Thomas
Date: Thu May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819
--- Comment #3 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:a2c593009fef1564dbef2237ee71e9fd08f5361e
commit r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e
Author: Paul Thomas
Date: Thu May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451
Bug ID: 100451
Summary: g++.dg/warn/Warray-bounds-20.C XPASSes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Rainer Orth ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452
Bug ID: 100452
Summary: g++.dg/vect/slp-pr99971.cc FAILs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452
--- Comment #1 from Rainer Orth ---
Created attachment 50766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50766&action=edit
32-bit sparc-sun-solaris2.11 slp-pr99971.cc.179t.slp2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #9 from Uroš Bizjak ---
ix86_use_mask_cmp_p should be refined, it has an early return for 64bit modes:
if (GET_MODE_SIZE (mode) == 64)
return true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
--- Comment #6 from Alex Coplan ---
On the GCC 10 branch it was the backport of the PR99037 fix which stopped the
ICE (r11-7888-g37d9074e12082132ae62c12fbe958c697f638c0a on trunk,
r10-9628-g1a92899b08e61d503a2897f2f66b064eb84706bc on the branch)
algorithms: zlib
gcc version 12.0.0 20210506 (experimental) [master revision
1698f496c5e:27b373b33d4:a1ac9ffb5a7f44b2e2633b7265c21ce803c8e854] (GCC)
[514] %
[514] % gcctk -O0 small.c; ./a.out
[515] % gcc110 -O1 small.c; ./a.out
[516] %
[516] % gcctk -O1 small.c
[517] % ./a.out
Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100455
Bug ID: 100455
Summary: [11 regression9 Obsoltee Template paraeter Cann
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
1 - 100 of 174 matches
Mail list logo
