https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48092
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98532
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #8 from Janez Zemva ---
I took a look and I believe the c_global is already being selected and I
believe the hack I presented should perhaps be applied to
libstdc++-v3/include/c_global/cmath - the hack template is in there. As for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2017-08-28 00:00:00 |2023-5-11
--- Comment #8 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
--- Comment #6 from Andrew Pinski ---
On the trunk we get at -O2:
.L2:
leaq(%rdi,%rax), %rcx
leaq(%rsi,%rax), %rdx
movapd (%rdx), %xmm0
addpd (%rcx), %xmm0
movaps %xmm0, -64(%rsp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #4 from Andrew Pinski ---
Using:
typedef uint64_t ua64_t __attribute__((aligned(1), may_alias));
#define UNALIGNED_LOAD64(_p) (*reinterpret_cast(_p))
#define UNALIGNED_STORE64(_p, _val) (*reinterpret_cast(_p) = (_val))
Does fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #3 from Andrew Pinski ---
The second issue an buffer overflow:
-O0 -fsanitize=undefined -fsanitize=address, we get:
/app/example.cpp:19:9: runtime error: store to misaligned address
0x7f4fad20002c for type 'uint64_t', which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
--- Comment #4 from alex at zrythm dot org ---
I have simplified the test source file using cvise. This can now be reproduced
with:
```
LANG=C gcc -fanalyzer -Werror=analyzer-use-of-uninitialized-value -c
audio_exporter6.c.i
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
alex at zrythm dot org changed:
What|Removed |Added
Attachment #55028|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #2 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
(In reply to Andrew Pinski from comment #1)
> Two issues which make this undefined. First the unaligned macros still use
> aligned types which gcc uses for alignment of the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
alex at zrythm dot org changed:
What|Removed |Added
Attachment #55029|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
Bug ID: 109821
Summary: vect: Different output with -O2 -ftree-loop-vectorize
compared to -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #22 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #21)
> (In reply to Jiu Fu Guo from comment #20)
> > Interesting thing:
> > the VR is always VR_VARYING, even for the below simple case:
> >
> > typedef unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #5 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:c787f593e62869ae0b230949b4791f4f3a26e50e
commit r14-743-gc787f593e62869ae0b230949b4791f4f3a26e50e
Author: Gaius Mulley
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #7 from Jonathan Wakely ---
Some of the libstdc++ changes in
https://aur.archlinux.org/cgit/aur.git/tree/gcc-djgpp.diff?h=dosbox-gcc would
be great to upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #37 from joseph at codesourcery dot com ---
If _BitInt constants aren't INTEGER_CST, then all places that expect that
any integer constant expression is folded to an INTEGER_CST will need
updating to handle whatever tree code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #4 from Gaius Mulley ---
The patch improves the error virtual token accuracy, for example:
$ gm2 -g highice.mod
highice.mod:6:6: error: string constant ‘12’ is too large to be assigned to the
array ‘a’
6 |a := '12'
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #3 from Gaius Mulley ---
Created attachment 55059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55059=edit
Proposed fix
Here is a proposed patch with test code which has successfully bootstrapped on
x86_64 linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
--- Comment #2 from Tobias Burnus ---
The not-doing LTO sounds as if we want to handle this by passing some arg that
gets processed in
lto-plugin/lto-plugin.c's process_option
possibly besides other places that need to be updated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109820
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109820
Bug ID: 109820
Summary: False-positive in tautological-compare
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #8 from Tobias Burnus ---
First, I want to remark that inside lto_output_toplevel_asms,
lto_stream_offload_p is true even with -flto.
However, the following is for output_symtab:
(In reply to Jakub Jelinek from comment #7)
> Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #6 from Janez Zemva ---
There are a lot of patches and I never went over all of them. I'll take another
look and update my bug report, if necessary (I think you're probably right).
But, should anyone else want to, the build script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
Bug ID: 109819
Summary: [OpenMP][OpenACC] -fno-lto effectively disables
offloading
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openacc, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #5 from Jonathan Wakely ---
And the $build-dir/$target/libstdc++-v3/config.log file should show the output
from this:
AC_MSG_NOTICE("C" header strategy set to $enable_cheaders)
That would confirm if it's being set to c_std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #4 from Jonathan Wakely ---
Hmm, I don't see anything in the configure scripts that would cause c_std to be
used implicitly for djgpp (or any other target). Maybe there's a local patch
applied to the djgpp copy of GCC sources?
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #7 from Jakub Jelinek ---
Not
--- gcc/lto-cgraph.cc 2023-01-09 13:30:47.105343886 +0100
+++ gcc/lto-cgraph.cc 2023-05-11 23:05:54.266991677 +0200
@@ -1023,7 +1023,8 @@ output_symtab (void)
if (!asm_nodes_output)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #3 from Janez Zemva ---
I am the "maintainer" of this dosbox-gcc aur (mostly I just borrow from other
builds). I have told the DJGPP community about this issue 2 times and they
shrugged it off, since they mostly compile .c source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #6 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #5)
> The above can work only if toplevel asms are in separate section and so
> inputting it or not doesn't affect input of other data.
> I think it would be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #9 from Amyspark ---
(In reply to Andrew Pinski from comment #7)
> Simple testcase:
> ```
> struct basic_string {
> ~basic_string() { }
> };
> const basic_string data[] = { {} };
> ```
>
> This fails with `ulimit -s 1024` which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
Patrick Palka changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:02777f20be4f40160f1b4ed34fa59ba75245b5b7
commit r14-742-g02777f20be4f40160f1b4ed34fa59ba75245b5b7
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #8 from Alexander Monakov ---
Ah, forgot to mention that compiler the offending User.cpp without -flto also
avoids the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109772
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:aa39ed4467db0cf18f300fcf475e09c4496527cf
commit r14-740-gaa39ed4467db0cf18f300fcf475e09c4496527cf
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #5 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > And we emit all toplevel asms into the offloading target code?
> > Or how does it make into PTX?
>
> It seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #2 from Jonathan Wakely ---
Also:
if test $enable_cheaders = c_std ; then
AC_MSG_WARN([the --enable-cheaders=c_std configuration is obsolete,
c_global should be used instead])
AC_MSG_WARN([if you are unable to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #1 from Jonathan Wakely ---
This means djgpp is doing this:
dnl To use the obsolete 'c_std' headers use --enable-cheaders-obsolete as
dnl well as --enable-cheaders=c_std, otherwise configure will fail.
Any idea why?
As it says,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #4 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #3)
> And we emit all toplevel asms into the offloading target code?
> Or how does it make into PTX?
It seems as if this is always written (once). Thus, the minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87102
John David Anglin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #10 from Martin Jambor ---
The patch from comment #9 does fix the regression. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #7 from Alexander Monakov ---
This problem seems to go way back. I'm told even gcc-9 broke LLVM like that.
For my investigation, I took latest gcc-11 snapshot and llvm-13.0.1.
My conclusion that it is a lifetime-dse violation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109738
--- Comment #3 from Scott Zhong ---
Is it very problematic if this is the correct behavior C++20 behaviour. For
example,
#include
#include
struct IntWrapper {
int value;
constexpr IntWrapper(int value): value{value} { }
auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #8 from Andrew Pinski ---
(In reply to Arsen Arsenović from comment #7)
> the thing with newlib in particular is that it's not really freestanding..
> it lives in an odd limbo between a full hosted OS and 'real' freestanding
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #9 from Uroš Bizjak ---
Created attachment 55057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55057=edit
Patch to enable mulv2si for TARGET_SSE4_1 only
The alternative approach is to enable mulv2si for TARGET_SSE4_1 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89786
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.2
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #7 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:10a0d98356680a387b69f8659099450f7af86d9f
commit r14-713-g10a0d98356680a387b69f8659099450f7af86d9f
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #3 from Jakub Jelinek ---
And we emit all toplevel asms into the offloading target code?
Or how does it make into PTX?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Bug ID: 109818
Summary: std::trunc() requires a hack after building
DJGPP
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #2 from Tobias Burnus ---
(In reply to Andrew Pinski from comment #1)
> Then _GLIBCXX_SYMVER_GNU should not be defined for NVPTX
It isn't – but with offloading, we only parse the file once — and then only
later generate for
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
$ ~/gcc/results.20230511.others/bin/gcc -c -O2
./gnat.dg/sync_iface_call_pkg2.adb
during IPA pass: icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89786
--- Comment #2 from David Binderman ---
-O1 seems sufficient to reproduce the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #36 from Jakub Jelinek ---
Created attachment 55056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55056=edit
gcc14-bitint-wip.patch
Just WIP on the top of the above patch, which does parsing of the _BitInt type
specifier in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #1 from Andrew Pinski ---
Then _GLIBCXX_SYMVER_GNU should not be defined for NVPTX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #35 from Jakub Jelinek ---
Created attachment 55055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55055=edit
gcc14-set-precision.patch
Untested preparation patch which prepares fo the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #6 from Andrew Pinski ---
Reducing (I can get the fault if we reduce the stack limit down to 1024 on
Linux via `ulimit -s 1024` ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
Bug ID: 109816
Summary: [14 Regression] r14-321 fix for PR108969 breaks NVPTX
offloading due to __asm (".globl
_ZSt21ios_base_library_initv")
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #6 from Jonathan Wakely ---
Thanks for the extra info.
I don't think it's really _forbidden_, but not a use case I was really aware
of, and didn't realise it's something we might need to support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #20 from Alexander Monakov ---
I missed it the first time around, but placing PAREN_EXPR around the complete
expression won't work: nothing will prevent GCC from duplicating evaluations of
the sub-expressions, and then randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #21 from Andrew Pinski ---
(In reply to Jiu Fu Guo from comment #20)
> Interesting thing:
> the VR is always VR_VARYING, even for the below simple case:
>
> typedef unsigned long INT;
> INT __attribute__ ((noinline)) foo (INT x)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89556
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673
--- Comment #3 from David SAUVAGE - AdaLabs
---
Created attachment 55054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55054=edit
reproducer (fixed)
Issue with the reproducer fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89159
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87170
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79710
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89742
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-05-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86391
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82746
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83188
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87102
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed|2019-03-10 00:00:00 |2023-05-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
Eric Botcazou changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #5 from lesto fante ---
> Presumably you're using newlib to provide the libm functions that
> declares?
newlib-nano, trough the "-specs=nano.specs".
Removing -ffreestanding in my project caused a decrease(!) in code size (42008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83310
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83002
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93702
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99099
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102164
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89786
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91324
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105212
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-05-11
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106169
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106318
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #8 from Martin Jambor ---
(In reply to Uroš Bizjak from comment #7)
>
> Martin, does this patch fix the runtime regression?
No, unfortunately it does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107392
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108610
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #4 from Jonathan Wakely ---
(In reply to lesto fante from comment #0)
> My code stop compiling after updating from
> arm-none-eabi-gcc (Arch Repository) 12.2.0
> to
> arm-none-eabi-gcc (Arch Repository) 13.1.0
> (cant easily test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-11
Known to work|
1 - 100 of 202 matches
Mail list logo
