https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #335 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #334)
> Created attachment 59216 [details]
> a patch to fix ICE in c#331
>
> The patch preallocates R0 for those Sid memory patterns so as to shorten t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #334 from Kazumoto Kojima ---
Created attachment 59216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59216&action=edit
a patch to fix ICE in c#331
The patch preallocates R0 for those Sid memory patterns so as to shorten the
li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #333 from Kazumoto Kojima ---
Created attachment 59215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59215&action=edit
a reduced test case for c#331
Looks yet another R0 starvation issue similar to c#133 but this time for SFmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116874
Bug ID: 116874
Summary: phiprop should handle more than just `a->t`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116874
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116873
Bug ID: 116873
Summary: esra does not remove unused store sometimes
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116835
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Phiprop use commit on the edge, maybe that could be improved/changed.
That won't work because the edges which are in use here are the edges of the
PHI.
Still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #7 from Michael Kenzel ---
Oh. Looks like I was looking at the wrong table… Sorry about that 😅
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #6 from Andrew Pinski ---
00B5;MICRO SIGN;So;0;ON; 03BCN;
# Decomposition mappings retain the tag from
# Unicode 2.0, even though the distinction between
# canonical and compatibility decompositions was not yet
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #5 from Andrew Pinski ---
https://www.compart.com/en/unicode/U+00B5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #4 from Michael Kenzel ---
Quoting [lex.name]/1 (https://eel.is/c++draft/lex.name#1.sentence-2):
The program is ill-formed if an identifier does not conform to Normalization
Form C as specified in the Unicode Standard.
According to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #3 from Nathaniel Shead ---
There is a warning -Wnormalized
(https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wnormalized_003d)
but as far as I can see it doesn't seem to do anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #2 from Andrew Pinski ---
Nor MSVC.
Are you 100% sure this is invalid code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
--- Comment #1 from Andrew Pinski ---
clang, EDG does not reject this either ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872
Bug ID: 116872
Summary: gcc accepts unnormalized identifiers
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #23 from GCC Commits ---
The trunk branch has been updated by Gerald Pfeifer :
https://gcc.gnu.org/g:2531f014fb2364777fb1ce09641db85bda5883b7
commit r15-3941-g2531f014fb2364777fb1ce09641db85bda5883b7
Author: Gerald Pfeifer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 116160, which changed state.
Bug 116160 Summary: [DR36] Rejects repeated using-declaration `using A::x;`
[namespace.udecl]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116160
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116160
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
Nathaniel Shead changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116803
Nathaniel Shead changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 116803, which changed state.
Bug 116803 Summary: Linkage fails if modules are compiled in a certain order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116803
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116160
--- Comment #5 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:2196a20b82bdde2aeb099bcfd164fa29a698e837
commit r15-3939-g2196a20b82bdde2aeb099bcfd164fa29a698e837
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
--- Comment #7 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:b9ac51a843f9dc807b00ab7f49f64968807a4ee8
commit r15-3938-gb9ac51a843f9dc807b00ab7f49f64968807a4ee8
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851
--- Comment #7 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:b9ac51a843f9dc807b00ab7f49f64968807a4ee8
commit r15-3938-gb9ac51a843f9dc807b00ab7f49f64968807a4ee8
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116803
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:cf9efe5ec14fea3ad5746fbefb22544bb9424d9d
commit r15-3937-gcf9efe5ec14fea3ad5746fbefb22544bb9424d9d
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116868
--- Comment #2 from Jonathan Wakely ---
Yes, they're all the same bug, and depend on Bug 110137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871
--- Comment #2 from Sam James ---
This matters more when you have quite long typedefs and the difference is just
a const on one parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871
--- Comment #1 from Sam James ---
tbh, I actually think we could do a bit better again and somehow annotate &f in
the diagram and colourise the 'float' vs 'int'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871
Sam James changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871
Bug ID: 116871
Summary: -Wincompatible-pointer-types for function pointers
could highlight the mismatch better
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #5 from David Malcolm ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:
Is it possible to do this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116870
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Target|mingw-w64-x86_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869
--- Comment #3 from jwjagersma at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
> msdosdjgpp might be the only target which does not define
> NO_PROFILE_COUNTERS .
I figured as much, but wasn't sure. From briefly poking around i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116870
Bug ID: 116870
Summary: Corrupt executable created by GCC 14.2 on Windows
MinGW64 with mingw-w64-x86_64-toolchain
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867
--- Comment #3 from Heng Zhou ---
(In reply to Andrew Pinski from comment #1)
> Looks to be already fixed in GCC 13.3.0.
Yes, it works with gcc 13.3. Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
--- Comment #16 from Heng Zhou ---
(In reply to Jakub Jelinek from comment #13)
> Fixed also for 13.3.
Yes, it works with gcc 13.3. Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869
--- Comment #1 from Andrew Pinski ---
msdosdjgpp might be the only target which does not define NO_PROFILE_COUNTERS .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> msdosdjgpp might be the only target which does not define
> NO_PROFILE_COUNTERS .
I should say for x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869
Bug ID: 116869
Summary: Profiler count register conflicts with regparm
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115919
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #4 from David Malcolm ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:
...in Compiler Explorer a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116868
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Marek Polacek changed:
What|Removed |Added
CC||hzhou11 at students dot
kennesaw.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 116867, which changed state.
Bug 116867 Summary: Incorrectly report a constexpr function as non-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116868
Bug ID: 116868
Summary: GCC trunk doesn't eliminate a superfluous new/delete
pair
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102594
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:96e0370f4daef29b918aafcff68c7f5e4ef397fd
commit r15-3933-g96e0370f4daef29b918aafcff68c7f5e4ef397fd
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867
Bug ID: 116867
Summary: Incorrectly report a constexpr function as
non-constant
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #3 from Jonathan Wakely ---
If we add [[nodiscard]] to the constructors of the standard exception types
then we get a warning with no compiler changes needed:
struct Exception
{
[[nodiscard]] Exception(const char*) { }
};
int d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102594
--- Comment #4 from Marek Polacek ---
Fixed on trunk so far. I think it makes sense to backport to 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #2 from David Malcolm ---
A simple example:
#include
int divide(int num, int denom) {
if (denom == 0)
std::invalid_argument ("division by zero"); // forgot "throw"
return num / denom;
}
which compiles with -Wall wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #1 from Andrew Pinski ---
>We could add [[nodiscard]] to the class declaration, but I think that doesn't
>actually work with gcc right now (it doesn't warn when it should)
That would be PR 85973 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
Bug ID: 116866
Summary: RFE: warn about suspected missing "throw" when
discarding temporaries that inherit from
std::exception
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
--- Comment #2 from Andrew Pinski ---
./cc1 -fanalyzer t.i -quiet -O2
during IPA pass: analyzer
src/numfmt.c: In function ‘unit_to_umax’:
src/numfmt.c:843:53: internal compiler error: in build2, at tree.cc:5099
0x25cc02e internal_error(char cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
--- Comment #1 from Andrew Pinski ---
if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
&& arg0 && arg1 && tt && POINTER_TYPE_P (tt)
/* When sizetype precision doesn't match that of pointers
we need to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
Bug ID: 116865
Summary: ICE when compiling GNU coreutils numfmt with
-fanalyzer
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Keywords: ice-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pan2.li at intel dot com
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116864
Bug ID: 116864
Summary: "*" and ".." in false positive
-Wanalyzer-use-of-uninitialized-value
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #57 from Andrew Macleod ---
FWIW, on my last run, enabling early VRP sped up my -O1 compilation by a fair
amount. total compilation dropped from 480 seconds to 380 seconds...
It took 2.5 seconds to run, and im going to guess might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116753
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116842
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-09-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #18 from Thiago Macieira ---
(In reply to Uroš Bizjak from comment #16)
> --quote--
> Note, that clearing the RDRAND CPUID bit does not prevent a processor
> that normally supports the RDRAND instruction from executing it. So any
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #17 from Thiago Macieira ---
(In reply to comment #8)
> I have to disagree. I specifically stated in the Qt bug that affected users
> were using -march=native and that was being resolved to -march=bdver4, so
> everything is not fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Robert Hölzl changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
--- Comment #3 from Jakub Jelinek ---
Even on targets like riscv, if one tries
int cmp1(int d1, int d2, int d3) {
if (((d1 ^ d2) & 0xabcd) == 0 || d3 != 42 || d1 != d2)
return 0;
return 1;
}
(i.e. inserts in between completely unrelated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116863
--- Comment #1 from Andrew Pinski ---
Can you report this upstream to LLVM (libsanitizer upstream is LLVM) since I
suspect you will hit it with tsan with LLVM too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852
--- Comment #4 from Jörg Richter ---
> I don't think there's a way besides wrapping those inside #pragma GCC
> visibility, using attributes and/or -fvisibility
I had hoped the point of -fvisibility-inlines-hidden is to not have to do this
in s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56556
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147
Pierre Ossman changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197
--- Comment #10 from Sam James ---
We're hitting this now, not sure how we didn't before.
conntrack.i:
```
enum a { b } register_dccp();
void c();
void __attribute__((noreturn)) exit_error(enum a d) {
__builtin_va_end(0);
if (d)
c();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:64072e60b1599ae7d347c2cdee46c3b0e37fc338
commit r15-3929-g64072e60b1599ae7d347c2cdee46c3b0e37fc338
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #16 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ddc72ba6c6c2c84a1a95340840bd5fde1f2bde44
commit r15-3928-gddc72ba6c6c2c84a1a95340840bd5fde1f2bde44
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Robert Hölzl changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 77885, which changed state.
Bug 77885 Summary: [Coarray] [OOP] ICE in gfc_add_class_array_ref, at
fortran/class.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 77873, which changed state.
Bug 77873 Summary: [Coarray] [OOP] ICE in gfc_is_class_scalar_expr, at
fortran/class.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77873
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77873
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #12 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:cd430b1fd95dce5868ce6a8063119d253ea2f995
commit r15-3926-gcd430b1fd95dce5868ce6a8063119d253ea2f995
Author: Pan Li
Date: Fri Sep 27 11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:7051fa5fa4eaa24785a64072490c1e0c65039915
commit r12-10729-g7051fa5fa4eaa24785a64072490c1e0c65039915
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
--- Comment #8 from Richard Earnshaw ---
BTW, rewriting the code as:
#include
typedef uint32_t __attribute__((aligned(1))) u32_u;
void f()
{
static uint8_t array[64];
for (uint8_t i = 0; i < sizeof(array); i++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
Arsen Arsenović changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #31 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:dd5b823ce238161156e7a4b6267bd30d7dde7c6b
commit r15-3924-gdd5b823ce238161156e7a4b6267bd30d7dde7c6b
Author: Mark Mentovai
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Arsen Arsenovic :
https://gcc.gnu.org/g:05e4f07cad1eacf869c10622cae2a9cdee3b6a7a
commit r15-3921-g05e4f07cad1eacf869c10622cae2a9cdee3b6a7a
Author: Arsen ArsenoviÄ
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
--- Comment #14 from GCC Commits ---
The trunk branch has been updated by Arsen Arsenovic :
https://gcc.gnu.org/g:d888a8a8dcf391197ae82e2bbf99507effc27950
commit r15-3923-gd888a8a8dcf391197ae82e2bbf99507effc27950
Author: Arsen ArsenoviÄ
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789
--- Comment #16 from Rémi Verschelde ---
Just noting that this is still reproducible in GCC 14.2 (14.2.1 20240912 (Red
Hat 14.2.1-3)), with the reproducers from comment 7 and comment 9.
I see it had milestone moved to successive 12.x minor rele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #16 from Uroš Bizjak ---
(In reply to GGanesh from comment #15)
> I wanted to get it confirmed from our BIOS and Kernel developer manuals
> (https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/
> programmer-references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:f7037fd03ad842dc69e20c03942f29d982ad655e
commit r13-9058-gf7037fd03ad842dc69e20c03942f29d982ad655e
Author: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
1 - 100 of 115 matches
Mail list logo
