Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially I observed the failure as a test failure on nlohmann_json-3.11.2
against gcc-14 master (r14-395-g1adb1a653d6739):
33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #3 from Sergei Trofimovich ---
Both -O1 and -fno-strict-aliasing remove the bug:
$ g++-14 unit-t.cpp -O2 -Ijson/include -o a -O1 && ./a
SUCCESS!
$ g++-14 unit-t.cpp -O2 -Ijson/include -o a -fno-strict-aliasing && ./a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #12 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #11)
> Created attachment 54999 [details]
> Patch which needs a message/changelog
I confirm the patch fixes real test failures on nlohmann_json-3.11.2 as well.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed when reduced example manually. Was a bit confused by an underline under
the class and not the method:
// $ cat a.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #28 from Sergei Trofimovich ---
(In reply to Miklos Karacsony from comment #27)
> (In reply to Sergei Trofimovich from comment #26)
> > #c12 fixed elfutils case.
>
> That's not accurate. It's only fixed if you use the default "-O2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #30 from Sergei Trofimovich ---
> configure: WARNING: unrecognized options: --disable-werror
> In function 'bigger_buffer',
> inlined from '__libdw_gunzip' at gzip.c:374:12:
> gzip.c:96:9: error: pointer may be used after 'reallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #32 from Sergei Trofimovich ---
Created attachment 55068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55068&action=edit
gzip.c.c
> > You should be able to extract preprocessed file using
> > https://gcc.gnu.org/bugs/#need: y
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
This week's gcc r14-799-g6190a74ebee694 ICEs on libaom-3.6.0. Minimal
reproducer:
// $ cat pickrst
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
mcfgthread-1.6.1 build failure started happening a few days ago on `gcc`
`master`. On r15-116
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
Sergei Trofimovich changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #9 from Sergei Trofimovich ---
The mcfgthread change fixed the full gcc build for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #17 from Sergei Trofimovich ---
> 1) attach your *.s file and state which exact compiler you used (revision)
Generate code first:
https://slyfox.uni.cx/b/gcc/PR114872/d.tar.gz (4MB, does not fit on bugzilla's
1MB limit)
is the arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #18 from Sergei Trofimovich ---
> 2) ideally show a gdb session with the important events, which setjmp was it
> (I see _setjmp and __sigsetjmp calls in the function), which exact function
> called from the function ended up aborti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #21 from Sergei Trofimovich ---
Good point! I wonder if I'm looking at the backtrace too late (or at the wrong
one). I'll retry again this evening and will extract more context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #22 from Sergei Trofimovich ---
Trying again to catch more precise place for SIGABRT.
Beginning at the start of the possibly aborting function:
(gdb) break __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__
(gdb) co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #23 from Sergei Trofimovich ---
At SIGSEGV site the code is an unconditional NULL dereference due to
dereference of `xor %esi,%esi` result from `gdb`.
797 if (op != _Py_NULL) {
0x7f940c871563 <+2563>: cmpq $0x0,-0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #25 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #24)
> (In reply to Sergei Trofimovich from comment #23)
> [...]
> > Why did `gcc` generate unconditional NULL dereference here? I suspect it
> > somehow inferr
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially I observed the testsuite failure on highway-1.0.7 library as on
r15-523-g1a05332bbac98a.
I reduced it down to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #1 from Sergei Trofimovich ---
If I understand the test correctly it uses 2^63 floating point value and
converts it to uint32_t (or int32_t?).
gcc's constant-fold saturates it to 2^63-1 while CPU keeps it at 2^63 (as if it
was uint3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #3 from Sergei Trofimovich ---
I might also have overzealously extracted simplified example from
highway-1.0.7: `gcc-14` (or older) do not fail on unmodified highway-1.0.7
testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #5 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #2)
> So from a point of view of float to int conversion, both are valid for out
> of range values.
Looking at CVTTPS2DQ instruction from
https://www.intel.com/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #7 from Sergei Trofimovich ---
Filed https://github.com/google/highway/issues/2183 on `highway` upstream side.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed as a test failures on highway-1.0.7 on
r15-644-g7422e050f33dd9 compiler:
HwyReverseTestGroup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #1 from Sergei Trofimovich ---
Specifically if I change original example to contain 16 bytes instead of 8:
--- bug.c.orig 2024-05-18 11:07:47.426351557 +0100
+++ bug.c 2024-05-18 11:08:02.135601287 +0100
@@ -15,2 +15,2 @@
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
Sergei Trofimovich changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
Sergei Trofimovich changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #4 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #3)
> Bisected down to r15-498-gc6cc6d4741a880
Sorry, should be r15-499-ga71f90c5a7ae29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #9 from Sergei Trofimovich ---
(In reply to Levy Hsu from comment #7)
> Created attachment 58236 [details]
> [PR]115146
The change fixed `highway-1.0.7` testsuite failure for me.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Created attachment 58250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58250&action=edit
bug.cc
Initially observed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Sergei Trofimovich changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #11 from Sergei Trofimovich ---
After `highway` applied a masking fix to `highway/master` `gcc-15` still fails
to pass the `HwyConvertTestGroup/HwyConvertTest.TestAllF2IPromoteTo/SSE2`.
I tried to reduce the test with more care and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #3 from Sergei Trofimovich ---
Looking at -O2's bug.cc.265t.optimized tree optimizations come up with unfolded
saturated sub8:
_12 = __builtin_ia32_psubusb128 ({ -65, 0, 0, 0, -65, 0, 0, 0, -65, 0, 0, 0,
-65, 0, 0, 0 }, { -99, 0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #8 from Sergei Trofimovich ---
Thank you, Jakub!
> The reason the testcase FAILs is the same as in the other PRs, it is trying
> to convert {0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f} V4SFmode vector
> to V4SImode, and becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #14 from Sergei Trofimovich ---
Created attachment 58265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58265&action=edit
shorter-bug.cc
I shrunk bug.cc slightly further into shorter-bug.cc and now it fails equally
on gcc-13 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #15 from Sergei Trofimovich ---
> I shrunk bug.cc slightly further into shorter-bug.cc and now it fails
> equally on gcc-13 and gcc-15. I agree that gcc-15 just got more constant
> folds available now, but otherwise it's behaviour di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #21 from Sergei Trofimovich ---
Shrunk the example down to a single simpler function while preserving the
original masking intent:
```c
cat bug.cc
#include
#include
#include
__attribute__((noipa))
static void assert_eq_p(void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #22 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #21)
gcc generates the following code for this C code:
> int main() {
> const __m128i su = _mm_set1_epi32(0x4f80);
> const __m128 sf = _mm_castsi
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Created attachment 58286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58286&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #24 from Sergei Trofimovich ---
Thank you, Alexander! Tricky `REG_EQUAL` makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #7 from Sergei Trofimovich ---
(In reply to Andrew Macleod from comment #6)
> Created attachment 58287 [details]
> proposed patch
>
> I'm testing this patch, does it resolve your problem?
>
> I forgot to free the gori_nmap object w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #14 from Sergei Trofimovich ---
The change fixed highway-1.0.7 test suite for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #27 from Sergei Trofimovich ---
The change fixed highway-1.0.7 test suite for me. Thank you!
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed on gcc master from r15--ge22b7f741ab54f today. There numpy on
i686-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115397
--- Comment #1 from Sergei Trofimovich ---
Debug build of the compiler is slightly more informative:
$ gcc -std=c99 -O3 -mavx512f -c bug.c.c -m32 -fPIC -fchecking=2
during RTL pass: split1
bug.c.c: In function 'LONG_divide_AVX512F':
bug.c.c:14:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115397
--- Comment #2 from Sergei Trofimovich ---
Bisect arrived at r15-1100-gec985bc97a0157, looks relevant:
commit ec985bc97a01577bca8307f986caba7ba7633cde
Author: Roger Sayle
Date: Fri Jun 7 13:57:23 2024 +0100
i386: Improve handling of ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115397
--- Comment #5 from Sergei Trofimovich ---
(In reply to Roger Sayle from comment #4)
> Created attachment 58386 [details]
> proposed patch
>
> This patch appears to fix (or more accurately workaround) the issue with this
> testcase.
The change
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
I was not able to extract small example yet from highway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403
--- Comment #1 from Sergei Trofimovich ---
Created attachment 58388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58388&action=edit
float_test.cc.cc.xz
Attaching preprocessed file. It fails as:
$ g++ -O2 -std=c++17 -c float_test.cc.cc
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403
--- Comment #2 from Sergei Trofimovich ---
`cvise` came up with this example:
//$ cat float_test.cc.cc
template __attribute__((always_inline)) inline void
AssertEqual() {}
void TestAllF16FromF32() { AssertEqual(); }
#pragma GCC
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
No minimal reproducer yet, filing in case it's an easy to notice bug from the
bisected r15-1113-gde05e44b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
--- Comment #2 from Sergei Trofimovich ---
Thank you for the hints!
I did not yet fully extracted self-contained example but got a bit closer to
it.
Comparing glibc binary before and after r15-1113-gde05e44b2ad963 the only
function that change
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
I think it's a regression started from r14-1433-gf150a084e25eaa
Noticed on `monotone-1.1` source code where `monotone` uses `#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111824
--- Comment #2 from Sergei Trofimovich ---
Sounds good.
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed on this week's build on i686-unknown-linux-gnu build/host/target.
How to reproduce against r14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #1 from Sergei Trofimovich ---
`diffoscope` says there is a difference in generated code in one of the
functions:
$ strip --strip-debug stage2-gcc-ira-build.o stage3-gcc-ira-build.o
$ diffoscope stage2-gcc-ira-build.o stage3-gcc-ira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #2 from Sergei Trofimovich ---
Reduced ira-build.cc down to the following:
// $ cat pp.cc.cc
typedef struct ira_object *ira_object_t;
struct ira_object {
void *conflicts_array;
int min, max;
};
void *ira_allocate(int);
int ira_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
Sergei Trofimovich changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #6 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #5)
> Bisected down to r14-4943-g8d2130a4e5ce36 "[RA]: Modfify cost calculation
> for dealing with equivalences"
Sorry, pasted wrong hash. That should be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #8 from Sergei Trofimovich ---
bootstrap with default options did not fail for me either. I had to use
--enable-checking=release to trigger the failure. I wonder if it exposes the
failure for you as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
Sergei Trofimovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE on today's gcc-master at r14-5043-g2b19c387696b0d. There it fails
to build binutils' gold. Extrac
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE today when attempted to build python-3.11.6 with gcc-master
r14-5055-g7480dbb6e7891f.
Extracted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #1 from Sergei Trofimovich ---
Slightly shorter example:
typedef union {
double d;
int L[2];
} U;
void d2b(int*);
void _Py_dg_dtoa(double dd) {
int be;
U u;
u.d = dd;
if ((&u)->L[1])
d2b(&be);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #6 from Sergei Trofimovich ---
I confirm that the fix also fixes original python-3.11.6 build failure. Thank
you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111653
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE on today's `gcc-master` r14-5073-g36a26298ec7dfc when building
jemalloc-5.3.0. Extracted the foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Sergei Trofimovich changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #2 from Sergei Trofimovich ---
A bit of debugging:
Program received signal SIGSEGV, Segmentation fault.
0x007bfff6 in convert_for_assignment (location=location@entry=263654,
expr_loc=expr_loc@entry=0, type=type@entry=0x7fffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #8 from Sergei Trofimovich ---
(In reply to Martin Uecker from comment #6)
> Created attachment 56491 [details]
> patch
>
> Ok, let's try again...
The change fixes jemalloc and boehm-gc builds for me. Thank you!
not used [-Werror=unused-function]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379
--- Comment #1 from Sergei Trofimovich ---
Proposed trivial fix by marking helper as `ATTRIBUTE_UNUSED`:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635194.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
statement
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Build failure i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467
--- Comment #2 from Sergei Trofimovich ---
Filed a feature request on `clang` side to consider implementing it:
https://github.com/llvm/llvm-project/issues/71858
Meanwhile would it be reasonable to enable the attribute only for `gcc`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE when was building linux-6.6.1 with gcc-master at
r14-5529-g7a496b7ce10518
cvise came up with the following trigger:
// $ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567
--- Comment #5 from Sergei Trofimovich ---
The fix allowed me to build linux-6.6.1 successfully with current gcc-master.
Thank you!
: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Encountered the bug when tried to build llvm-17.0.5 with -O1 optimization
flags
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
This is an example extracted from an attempt to debug PR112572.
Attached file is not directly executable. And it's not easy to amoend to make
it executable,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
--- Comment #1 from Sergei Trofimovich ---
Created attachment 56635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56635&action=edit
bug.cpp.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #19 from Sergei Trofimovich ---
I spent some time poking at the bug and was not able to reproduce it on my
toolchain.
I was able to get it to fail on gentoo's toolchain and arrived at problems in
lib/Target/X86/X86InterleavedAccess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
--- Comment #3 from Sergei Trofimovich ---
> since the bad instruction is a compare, it does seem like it might be solved
> via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 too. compare
> elimination is going wrong.
Yeah, that fixe
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially noticed possibly wrong code on llvm-16.0.6 test suite when building
with gcc-master from r14-5844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
--- Comment #3 from Sergei Trofimovich ---
I confirm bisect landed on r14-5831-gaae723d360ca26 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
--- Comment #9 from Sergei Trofimovich ---
The change also fixes llvm-16.0.6 testsuite for me. Thank you!
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed ICE on gcc-master at r14-6191-g9c3a880feecf81 compiling
libopenmpt-0.7.3.
Extracted example:
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869
--- Comment #3 from Sergei Trofimovich ---
I confirm the proposed change fixes build of libopenmpt-0.7.3 as well. Thank
you!
rsion: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
In https://github.com/NixOS/nixpkgs/issues/229470 Arnout Engelen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898
--- Comment #3 from Sergei Trofimovich ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Sergei Trofimovich from comment #0)
> > --- gcc-12.2.0/gcc/Makefile.in 2022-08-19 10:09:52.280658631 +0200
> > +++ gcc-12.2.0-new/gcc/Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #5 from Sergei Trofimovich ---
> For me it finishes in 3 minutes on gcc-14.
I'll take it back. It does not finish for me in 10 minutes on gcc-14. Don't
know where I picked the number.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #6 from Sergei Trofimovich ---
Created attachment 55174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55174&action=edit
packet-rnsap-shrunk-slightly.c.i.xz
packet-rnsap-shrunk-slightly.c.i.xz is a slightly shrunk version of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #7 from Sergei Trofimovich ---
Original packet-rnsap.c.i.xz takes 27 minutes to compile for me.
The hack below cuts this time down to 9 minutes (slashes 60% of runtime).
The considerable amount of time is spent looking up the bitm
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
This week's gcc r14-1423-gfefa7db2c31fee started failing pixman-0.42.2 test
suite:
pixman> FAIL: scaling-crash-test
pixman> FAIL: cover-test
pixman>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
Sergei Trofimovich changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
--- Comment #6 from Sergei Trofimovich ---
Adding configure flags for completeness (nothing special):
> Configured with:
configure flags: --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-6.2.1/lib
--w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
--- Comment #10 from Sergei Trofimovich ---
Thank you! I confirm the fix also fixed complete pixman-0.42.2 test suite.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
I initially observed the failure as an llvm-16 (and older) single test failure
when built by r14-1704-gff83d1b47aadcd
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Found an ICE on pycryptodome-3.17.0 when building
401 - 500 of 653 matches
Mail list logo
