https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103257
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288
--- Comment #12 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:1a15a91a0015208eafb797e4de1348c9877fd6d0
commit r12-5333-g1a15a91a0015208eafb797e4de1348c9877fd6d0
Author: Andrew Pinski
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103243
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2021-11-17
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #6 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #5)
> note that same error happens on older x86_64-linux debian boxes.
That has to be a totally different issue from here. This is specificially about
solaris specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103298
Bug ID: 103298
Summary: [12 regressions] regressions on arm after r12-5301
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880
--- Comment #11 from Andrew Pinski ---
(In reply to Christophe Lyon from comment #10)
> After r12-5301, on aarch64 I can see:
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps
> threaded: 18"
Yes it looks like Richard for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103298
--- Comment #1 from Andrew Pinski ---
(In reply to Christophe Lyon from comment #0)
> arm-none-linux-gnueabi -march=armv5t -mthumb:
> FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition
> chain with [^\n\r]* BBs transfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #6 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #5)
> I can confirm the ICE with current trunk both on x86_64 and
> on POWER.
>
> x86_64:
>
> $ gfortran -v
> Es werden eingebaute Spezifikationen verwendet.
> COLLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299
Bug ID: 103299
Summary: accessing incorrect storage for union at constexpr
context
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #13 from Martin Liška ---
(In reply to Jan Hubicka from comment #11)
> Thanks for reducing the testcase.
> I found the reason for build difference. There is misplaced code clearing
> to_info_lto.
Thanks! Great you found it so quic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> not sure why that only happens in the last phiopt pass. Ah, because
> the main phiopt pass sees the following:
>
>[local count: 1073741825]:
> if (d_3(D)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89018
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #14 from hubicka at kam dot mff.cuni.cz ---
> Thanks! Great you found it so quickly.
It is bit stupid code since everything is duplicated twice (for LTO and
non-LTO). I have to refactor it: we could have common base of the two
summari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95729
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #6 from Aldy Hernandez ---
This looks like a class of problems we could easily get if we wanted. The
pattern is:
PREHEADER
|
|
V
HEADER --> LOOPEXIT
|
|
V
SUCC
| \
| \
DEAD \
| /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #7 from Jonathan Wakely ---
The code can be reduced to this, which GCC, EDG and MSVC all accept, but Clang
doesn't:
struct S
{
union {
char buf[8];
char* ptr;
};
unsigned len;
constexpr S(const char* s, unsigned n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Mine, After PR 25290, the below match.pd pattern will just work :).
>
> (In reply to Marc Glisse from comment #3)
> > and something that could be auto-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #8 from Jonathan Wakely ---
Which means this is enough to make Clang happy for the comment 0 example:
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -167,6 +167,11 @@ _GLIBCXX_BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #9 from cqwrteur ---
(In reply to Jonathan Wakely from comment #8)
> Which means this is enough to make Clang happy for the comment 0 example:
>
> --- a/libstdc++-v3/include/bits/basic_string.tcc
> +++ b/libstdc++-v3/include/bits/ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #10 from Jonathan Wakely ---
(Do you really need to quote the whole of comment 9 to reply to comment 8?)
You can't, it's not freely available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49959
--- Comment #4 from Andrew Pinski ---
Note Pre is able to remove the casts since GCC 8.
So the original testcase is fixed but if you change it to:
#define ABS(X)(((X)>0)?(X):-(X))
unsigned long
test_abs(int *cur)
{
unsigned long sad = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #4 from Yury Gribov ---
(In reply to Andrew Pinski from comment #3)
> No the gimple is wrong. &var is taking the address of the argument. It
> should just be var here if you what the reference points to rather than the
> address of
compression algorithms: zlib
gcc version 12.0.0 2027 (experimental) [master r12-5333-g1a15a91a001] (GCC)
[597] %
[597] % gcctk -O2 small.c; ./a.out
[598] %
[598] % gcc110 -O3 small.c; ./a.out
[599] %
[599] % gcctk -O3 small.c
[600] % ./a.out
Aborted
[601] %
[601] % cat small.c
int a, b[2], c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #5 from Yury Gribov ---
Created attachment 51823
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51823&action=edit
Runnable reprocase
I've attached another reprocase which reproduces the error at runtime (but let
me reiterate t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103300
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Needs -O2 -floop-unroll-and-jam --param early-inlining-insns=14
to fail, so I guess it may be issue with unrol-and-jam.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103300
--- Comment #2 from hubicka at kam dot mff.cuni.cz ---
Needs -O2 -floop-unroll-and-jam --param early-inlining-insns=14
to fail, so I guess it may be issue with unrol-and-jam.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103301
Bug ID: 103301
Summary: co_broadcast: broadcast of an object of a derived type
with custom assignment operator defined
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103243
--- Comment #3 from Jan Hubicka ---
Does not reproduce for me on aarch64 (gcc114 from the compile farm)
jh@gcc114:~/trunk/build2/gcc$ ./xgcc -B ./ --version
xgcc (GCC) 12.0.0 2027 (experimental)
Copyright (C) 2021 Free Software Foundation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #4 from Aldy Hernandez ---
It's been a LONG time since I had to do a sim build, so please bear with me.
I have combined tree with gcc, binutils-gdb, dejagnu, newlib-cygwin:
~/src/combined/configure --target=bfin-elf --enable-langu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #5 from Aldy Hernandez ---
FWIW, the *.ch2 dump on both x86-64 and bfin-elf are identical.
This is unlikely to help, but...
In *.ivopts we start seeing differences in the IL:
[local count: 60236916]:
e = 1;
+ ivtmp.29_7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103297
--- Comment #1 from cqwrteur ---
Another issue
#include
#include
#include
inline constexpr std::string_view lifetime_detector(std::string const& str)
noexcept
{
return str;
}
inline constexpr bool test2(std::string_view vw2) noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103297
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103297
--- Comment #3 from Jonathan Wakely ---
(In reply to cqwrteur from comment #0)
> out_of_bounds_detector(buffer,buffer+7);//should give a hard error
This looks like PR 70151
(In reply to cqwrteur from comment #1)
> std::string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82876
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103297
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70151
Jonathan Wakely changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> It just doesn't allow assignment through the pointer.
I think that's correct according to [class.union.general] p6:
"When the left operand of an assignmen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jakub Jelinek ---
> Created attachment 51807
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51807&action=edit
> gcc12-pr102838-2.patch
>
> Does this patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #3 from Jonathan Wakely ---
This code from PR 103295 is kinda related, which GCC, EDG and MSVC all accept,
but Clang doesn't:
struct S
{
union {
char buf[8];
char* ptr;
};
unsigned len;
constexpr S(const char* s, un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #15 from Jan Hubicka ---
Yep, I still see difference in the output with and without SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #15 from Jakub Jelinek ---
Ah, bet Solaris aligned_alloc relies on:
"the value of size shall be an integral multiple of alignment"
(glibc aligned_alloc doesn't).
Does memalign or posix_memalign rely on that too, or just aligned_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103255
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c39cb6bf835ca12e590eaa6f90222e51be207c50
commit r12-5336-gc39cb6bf835ca12e590eaa6f90222e51be207c50
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #16 from Jan Hubicka ---
Building with LTO only ecpder.fppized.o and ecplib.fppized.o I get the failure
going away with --dbg-cnt=ipa_cp_values:10 and :9 works.
Different ipa-cp decision is
+***dbgcnt: upper limit 10 reached for ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675
--- Comment #20 from Gerald Pfeifer ---
Thank you, Jakub!
I finished testing/preparing the second part of the patch, just did not get
to push.
So I went ahead and gave your suggested patch a try - and it passes bootstrap,
so good to go I'd say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jakub Jelinek ---
> Ah, bet Solaris aligned_alloc relies on:
> "the value of size shall be an integral multiple of alignment"
> (glibc aligned_alloc doesn't).
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #17 from Jan Hubicka ---
and fun fact is that it really depends how program is paritioned.
-flto-partition=max keeps problem reproducing while -flto-partition=one makes
it go away and -flto-partition=one --disable-tree-modref2 bring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #10 from Hongtao.liu ---
I'm working on a patch which adds a new memory constraint "Bk" which will
exclude TLS UNSPECs for mask register alternative.
The UNSPEC i'm excluding is like below, any other UNSPEC needs to be added?
bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:077425c890927eefacb765ab5236060de9859e82
commit r12-5337-g077425c890927eefacb765ab5236060de9859e82
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #11 from H.J. Lu ---
(In reply to Hongtao.liu from comment #10)
> I'm working on a patch which adds a new memory constraint "Bk" which will
> exclude TLS UNSPECs for mask register alternative.
>
> The UNSPEC i'm excluding is like be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
Author: Martin Uecker
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
--- Comment #16 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
Author: Martin Uecker
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #18 from Jan Hubicka ---
This seems to fix it for this particular partitioning at least ;)
The problem was in summary update producing ill formed access range (which
doesn't know base but knows offset from it) and that confused strea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #12 from Jason A. Donenfeld ---
(It might be too late at this point to say it, but I thought it's worth
mentioning that another approach might be convincing the binutils people to
accept kmov/vmov/vex relocations.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Bug ID: 103302
Summary: wrong code with -fharden-compares
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #13 from Jakub Jelinek ---
If you read the tls.pdf, you'll see that it is not really possible, the IE ->
LE transition needs to change the instructions that read from the .got memory
to instructions that set the destination to an imm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299
Patrick Palka changed:
What|Removed |Added
Known to fail||11.2.0, 12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12 Regression] |[11/12 Regression]
|a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #12 from Jonathan Wakely ---
But even with those problems fixed, Clang fails for anything that doesn't fit
in the SSO buffer, as shown by this:
#include
constexpr char test()
{
char* p = std::allocator().allocate(2);
p[0] = '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278
--- Comment #3 from Jeffrey A. Law ---
Note we also see these regressions:
rl78-elf
if-to-switch-5
if-to-switch-9
xstormy16-elf
if-to-switch-9
sh3-linux-gnu
sh3eb-linux-gnu
gcc.target/sh/pr51244-19.c, but I think this is fixable with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713
--- Comment #1 from David Malcolm ---
Thanks for reporting this issue.
The analyzer sees that "str" is passed to hash_insert as a const pointer, and
therefore assumes that hash_insert cannot free it, that hash_insert is merely
borrowing a point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #7 from Tamar Christina ---
Just a note, in our case the error seems to cause stage2 build to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Tamar Christina changed:
What|Removed |Added
Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103303
Bug ID: 103303
Summary: compiler have trouble to point to the correct
destructor address while for large align objects with
complex inheritance while destruct object
Produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103304
Bug ID: 103304
Summary: tgmath returns incorrect results for float fma (fmaf)
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #8 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #7)
> Just a note, in our case the error seems to cause stage2 build to fail.
Please file a PR for it and indicate the architecture. This PR is for a
pr80974.c re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103243
--- Comment #4 from seurer at gcc dot gnu.org ---
At or somewhere just before r12-5221 it now succeeds, at least on powerpc64
g:2f3d43a35155685b1795b4392e20e1c14a33c38f, r12-5221
New passes (these tests previously failed but now do not):
FAIL: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103304
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855
Jonathan Wakely changed:
What|Removed |Added
CC||oscar.smith@juliacomputing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103304
--- Comment #2 from Jonathan Wakely ---
N.B. the same applies to printf: you included so you should be using
std::printf. Or you should include
Stop including C++ headers that put names in namespace std and then using them
as though they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Bug ID: 103305
Summary: [12 Regression] Cannot build aarch64-none-elf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: build, wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #9 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Tamar Christina from comment #7)
> > Just a note, in our case the error seems to cause stage2 build to fail.
>
> Please file a PR for it and ind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #10 from Jeffrey A. Law ---
Aldy, the trick is to not build the C++ runtime ;-)
So instead of "make" use "make all-gcc && make all-target-libgcc" to build the
compiler and libgcc runtime. Then use "make install-gcc install-target-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
--- Comment #4 from Jeffrey A. Law ---
I could also set up a toolchain ready-to-debug in an AWS instance that you
could use if that would be helpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
--- Comment #5 from Jeffrey A. Law ---
Ignore last comment. Meant for a different BZ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #11 from Jeffrey A. Law ---
Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
instance if that would be helpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #7 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #6)
> Really interesting, I don't get an ICE with the following setup:
> ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
> --with-mpfr=/usr/local/ --with-mp=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #12 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #9)
> (In reply to Aldy Hernandez from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > Just a note, in our case the error seems to cause stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103130
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:049f0efeaa77b43a508172161ca040feb6bb5622
commit r12-5340-g049f0efeaa77b43a508172161ca040feb6bb5622
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103130
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12 Regression] \*/ is |[11 Regression] \*/ is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Aldy Hernandez changed:
What|Removed |Added
Target|aarch64-none-elf|aarch64-none-elf, bfin-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #13 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #11)
> Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
> instance if that would be helpful.
Ok, I give up.
I configured and installed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:054bf99841aad3869c70643b2ba2d9f85770c980
commit r12-5342-g054bf99841aad3869c70643b2ba2d9f85770c980
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6afa1083c6ee7b31629fb0c16299b952cb17868c
commit r12-5343-g6afa1083c6ee7b31629fb0c16299b952cb17868c
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk, backports to follow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #4 from Aldy Hernandez ---
Is this still an issue with the latest trunk? There have been a few changes in
this space (phi ordering, loop header copying, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #5 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #4)
> Is this still an issue with the latest trunk? There have been a few changes
> in this space (phi ordering, loop header copying, etc).
At least on aarch64 our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #14 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Tamar Christina from comment #9)
> > (In reply to Aldy Hernandez from comment #8)
> > > (In reply to Tamar Christina from comment #7)
> > > > J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #3 from Tamar Christina ---
logs indicate that this started happening between
3ba1bd0d9dbc..2ec453b566ac on Nov 12. However that range contains a suspicious
newlib commit
https://github.com/bminor/newlib/commit/3ba1bd0d9dbc015c14a0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #4 from Tamar Christina ---
Looks like that commit moved the short named to ctype_.h instead of ctype.h.
I'm however unsure if this is something GCC needs to adapt to or if newlib
needs to fix this. They claim it now matches glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #5 from Jonathan Wakely ---
This should work:
--- a/libstdc++-v3/config/os/newlib/ctype_base.h
+++ b/libstdc++-v3/config/os/newlib/ctype_base.h
@@ -41,6 +41,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// NB: Offsets into ctype::_M_ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #15 from Jeffrey A. Law ---
Re: c#13. You were so close :-) Add "-msim" to your command line. THat's one
of the things the baseboards file does for you when you run things under
dejagnu on bfin-elf...
I've sent Aldy instructions
1 - 100 of 177 matches
Mail list logo
