https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118990
Andrew Pinski changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
--- Comment #5 from Yotam Medini ---
Created attachment 60568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60568&action=edit
bash script running g++ with -freport-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
--- Comment #6 from Yotam Medini ---
Created attachment 60569
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60569&action=edit
log of -freport-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
Bug ID: 118991
Summary: Wrong extracted text in avr.cc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118990
Bug ID: 118990
Summary: Probable typo in calls.cc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118988
--- Comment #1 from Andrew Pinski ---
"in between" is also correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118989
Bug ID: 118989
Summary: Missing explanation for
switch-lower-slow-alg-max-cases
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118988
Bug ID: 118988
Summary: Typos in param.opt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961
Nathaniel Shead changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |WAITING
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
--- Comment #4 from Andrew Pinski ---
Created attachment 60567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60567&action=edit
Reduced testcase
Fails with `-std=c++20 -O1`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87162
--- Comment #10 from Andrew Pinski ---
*** Bug 118987 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Jonathan Wakely changed:
What|Removed |Added
Summary|[15 Regression] |"_GLOBAL__sub_I.00099_tzdb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #39 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:d4a777d098d524a3f26c3db28e50d064a7a4407e
commit r15-7677-gd4a777d098d524a3f26c3db28e50d064a7a4407e
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118987
Bug ID: 118987
Summary: ICE: error reporting routines re-entered. (SIGSEGV in
calculate_dominance_info (dominance.cc:724)) with
-fdump-passes -fgnu-tm
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118987
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
--- Comment #2 from Andrew Pinski ---
Created attachment 60566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60566&action=edit
Non reduced (still including memory) testcase
ICEs with `-std=c++23 -O1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
Andrew Pinski changed:
What|Removed |Added
Summary|internal compiler error: in |[15 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #38 from Erich Löw ---
Using [[gnu::init_priority(0)]] (I saw it right now per coincidency)
produces error advise as follows:
main.cc:45:39: error: requested ‘init_priority’ 0 is out of range [0, 65535]
45 | [[gnu::init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #25 from Jonathan Wakely ---
Probably not, although an unintentional ABI break against C++11 for something
arguably unnecessary might get attention.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #37 from Erich Löw ---
I found in parallel as well that using 98 instead of 99 purges the "as"
generated error.
Not yet created a clean and simplified reproduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #11 from Andrew Pinski ---
Let me try again:
So we have:
__v4di v4 = ymm0
__v2di tmp = _mm256_extracti128_si256(v4, 1); // vextracti128
__v2di tmp1 = _mm256_castsi256_si128(v4); // subreg
__v2di v2 = tmp + tmp1;
__v2di v3 = _mm_shuf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #36 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #32)
> Note I think a workaround is to use 98. I think vtable-verify uses 99.
Aha, thanks. I'll make that change to workaround the problem for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #10 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Maxim Egorushkin from comment #8)
> > (In reply to Andrew Pinski from comment #6)
> > > If you look at the difference between the 2 functions.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Andrew Pinski changed:
What|Removed |Added
Attachment #60564|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction, wrong-code |
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #33 from Andrew Pinski ---
Created attachment 60564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60564&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-source
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #32 from Andrew Pinski ---
Note I think a workaround is to use 98. I think vtable-verify uses 99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
Bug ID: 118986
Summary: internal compiler error: in replace_decl, at
cp/constexpr.cc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #9 from Andrew Pinski ---
(In reply to Maxim Egorushkin from comment #8)
> (In reply to Andrew Pinski from comment #6)
> > If you look at the difference between the 2 functions.
> > vextracti128xmm1, ymm0, 0x1
> >
> > vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #8 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #6)
> If you look at the difference between the 2 functions.
> vextracti128xmm1, ymm0, 0x1
>
> vs
> vmovdqa xmm1, xmm0
> vextracti128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #7 from Andrew Pinski ---
(In reply to Maxim Egorushkin from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > Register allocation is NP complete problem after all.
>
> vmovdqa instruction probably intends to turn a ymm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
Andrew Pinski changed:
What|Removed |Added
Blocks|101926 |
--- Comment #6 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #5 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #2)
> Register allocation is NP complete problem after all.
vmovdqa instruction probably intends to turn a ymm register into a xmm register
by zeroing all the high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
Sam James changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #31 from Andrew Pinski ---
Reducing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #30 from Andrew Pinski ---
Created attachment 60562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60562&action=edit
Unreduced testcase
[apinski@xeond2 c++20]$ ~/upstream-gcc-isel/bin/g++ -c tzdb.ii -Wall -Wextra
-Wwrite-strin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117919
--- Comment #3 from Filip Kastl ---
I found that arguments of the PHI get removed because its whole basic block
gets removed. Actually, basic blocks 10-13 get removed. This happens in a
call to 'replace_uses_by' function. I think that EH edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #29 from Xi Ruo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Andrew Pinski changed:
What|Removed |Added
Component|libstdc++ |middle-end
--- Comment #28 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #26 from Andrew Pinski ---
Can you attach config.log from the gcc subdirectory in the build directory? I
am wondering if init_array detection is going wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118978
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118978
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a2f60c1ff5a85497f84dc307301bcbc4bd77082e
commit r15-7668-ga2f60c1ff5a85497f84dc307301bcbc4bd77082e
Author: Gaius Mulley
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118979
Andrew Pinski changed:
What|Removed |Added
CC||goeran at uddeborg dot se
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #25 from Erich Löw ---
With system GCC 15.0.1 I do as below
I created: main.cc
#include
#include
struct A { A() { } };
[[gnu::init_priority(99)]] A a;
[[gnu::init_priority(99)]] A a2;
struct B { B() { } };
[[gnu::init_prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118979
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-22
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118985
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2025-02-21 00:00:00 |2025-02-22
URL|https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118356
--- Comment #8 from Javier Mora ---
(In reply to Jeffrey A. Law from comment #7)
> For example, deeply embedded where
> codesize is particularly important likely won't want any code alignments.
> While other uarchs (say targetting a server mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #23 from Xi Ruoyao ---
I just tried bootstrapping GCC and I couldn't reproduce the failure. The
output assembly seems normal regarding _GLOBAL__sub_I.00099_tzdb.cc:
.section.text.startup._GLOBAL__sub_I.00099_tzdb.cc,"ax",@p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #22 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #24 from Peter Dimov ---
I already have
https://github.com/boostorg/uuid/blob/e7f4cebe81835fd1b5558178f3d4c40ae266d8e2/include/boost/uuid/time_generator_v1.hpp#L32-L43
but this comes with its own issues (-Wmissing-field-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118080
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #21 from Xi Ruoyao ---
(In reply to Erich Löw from comment #16)
> In parallel: how did I come to "CCFLAGS=-pipe -march=native -O2 -fPIC
> -fomit-frame-pointer"?
> --> They are from linux kernel compiling
This is not correct. The cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118080
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:02eedd2932e4c91f41437f56c34eee1a128c24fb
commit r14-11324-g02eedd2932e4c91f41437f56c34eee1a128c24fb
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #23 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #22)
> I'm not sure how to fix that problem without pessimizing every
> std::atomic::compare_exchange_strong to use the looping implementation
To be clear, not *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #22 from Jonathan Wakely ---
I'm not sure how to fix that problem without pessimizing every
std::atomic::compare_exchange_strong to use the looping implementation that
std::atomic_ref::compare_exchange_strong uses, or to find some
C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #19 from Erich Löw ---
Oki.
I do as you propose.
I'll report in next comment slice the outputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #18 from Jonathan Wakely ---
What happens if you compile this code using your existing system g++
struct A { A() { } };
[[gnu::init_priority(99)]] A a;
[[gnu::init_priority(99)]] A a2;
struct B { B() { } };
[[gnu::init_priority(99)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118982
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65115
--- Comment #3 from Jonathan Wakely ---
The docs for [[gnu::constructor(priority)]] imply that the default init
priority of 65535 is an unspecified implementation detail:
However, at present, the order in which constructors for C++ objects
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #19 from marcus at mc dot pp.se ---
If you don't have ARM hardware, the issue can be seen in qemu:
hakua:/tmp% uname -a
Linux hakua 5.4.275 #1 SMP Wed May 8 17:18:04 CEST 2024 ppc64 POWER9, altivec
supported PowerNV T2P9D01 REV 1.00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118985
Bug ID: 118985
Summary: Double quotes are missing when extracted for
translation from opt file
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #4 from Maxim Egorushkin ---
To add more context, I use Mula's AVX2 popcount function from
https://arxiv.org/abs/1611.07612
It produces 4 counts in a v4di register which should be summed into a scalar
total. Which brought me here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #17 from Erich Löw ---
Recompile from scratch with none additional CFLAGS, CCFLAGS et al done
Here the result
libtool: compile: /home/SETUP/GNU/gcc/BUILD/./gcc/xgcc -shared-libgcc
-B/home/SETUP/GNU/gcc/BUILD/./gcc -nostdinc++
-L/h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
Peter Cordes changed:
What|Removed |Added
CC||pcordes at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #18 from marcus at mc dot pp.se ---
vect-iv-7.c is probably a good (small) test case to start looking at.
The source code is scalar, but gets auto-vectorized by gcc 14 at -O2.
On big endian, the result arr[] becomes
10 8 14 12 18 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> It only shows up with arguments and returns due to register allocation
> constraints.
Acually I was wrong here.
but it is still by accident really.
Register al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #17 from marcus at mc dot pp.se ---
Created attachment 60561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60561&action=edit
Real regressions (PASS -> FAIL) from 13.3 to 14
So, I diffed gcc.sum between 13.3.1 and 14.3., an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #16 from Erich Löw ---
In parallel: how did I come to "CCFLAGS=-pipe -march=native -O2 -fPIC
-fomit-frame-pointer"?
--> They are from linux kernel compiling
--> And I thought 30 Years ago: let compile kernels and local LATEST GNU
omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #15 from Erich Löw ---
As proposed I do now:
- I deleted my whole BUILD dir
- I recreated BUILD dir as empty dir
- I unset CFLAGS, CPPFLAGS, CCFLAGS and CXXFLAGS
- I rerun configure steps in BUILD dir
- I say ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #1 from Andrew Pinski ---
It only shows up with arguments and returns due to register allocation
constraints.
I am not sure if this is that important.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
Bug ID: 118984
Summary: Unnecessary instructions are emitted when addition
terms are in an unfortunate order
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
S
77 matches
Mail list logo
