https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105881
Bug ID: 105881
Summary: GCC release mode can crash Torque3D
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #6 from Chris Johns ---
(In reply to Andrew Pinski from comment #5)
> There has to be an ordering issue of the calling of the deconstructors vs
> the ordering of the constructors.
>
> Maybe the problem is the `eh_gloabls init` prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #5 from Andrew Pinski ---
There has to be an ordering issue of the calling of the deconstructors vs the
ordering of the constructors.
Maybe the problem is the `eh_gloabls init` priority is not set correctly to be
first/last.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #4 from Chris Johns ---
(In reply to Andrew Pinski from comment #3)
> Sounds like the order of deconstructors is wrong.
> Where is __cxxabiv1::__cxa_get_globals being called from that is the problem?
The `std::ios_base::Init::~Init(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #3 from Andrew Pinski ---
Sounds like the order of deconstructors is wrong.
Where is __cxxabiv1::__cxa_get_globals being called from that is the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #2 from Andrew Pinski ---
(In reply to Sebastian Huber from comment #1)
> Just for reference, the destructor code is (eh_globals.cc):
>
> struct __eh_globals_init
> {
> __gthread_key_t _M_key;
> bool_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
Bug ID: 105880
Summary: eh_globals_init destructor not setting _M_init to
false
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105879
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105879
Bug ID: 105879
Summary: DI mode constants are incorrectly loaded into
registers on big-endian xtensa
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105504
--- Comment #6 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
commit r13-1009-g5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
Author: liuhongt
Date: Mon May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #10 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
commit r13-1009-g5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
Author: liuhongt
Date: Mon May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #6 from Hongtao.liu ---
Fixed in trunk, GCC12.2 and GCC11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:c45a9752f15bbc37d8efda0e29af5a2bfd53729d
commit r12-8462-gc45a9752f15bbc37d8efda0e29af5a2bfd53729d
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:66b1b04bb59fbafb809bfad945c95888b758e719
commit r11-10053-g66b1b04bb59fbafb809bfad945c95888b758e719
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #3 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:e4bdeaba6ef8a83877417f7ec172fd8743370284
commit r13-1008-ge4bdeaba6ef8a83877417f7ec172fd8743370284
Author: liuhongt
Date: Wed Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
--- Comment #5 from JUN SHA ---
(In reply to Andreas Schwab from comment #4)
> The situation hasn't changed in the last 7 months.
Do you know the most recent commit id where asan can work correctly 7 months
ago?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105878
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105878
Bug ID: 105878
Summary: Error message for const usage inside a capture should
be improved
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #18 from Eric Gallager ---
-Wmissing-declarations came up as a possibility for this in IRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810
--- Comment #4 from cqwrteur ---
(In reply to cqwrteur from comment #3)
> (In reply to Jonathan Wakely from comment #2)
> > Specifically, the suggested implementation is:
> >
> > template
> > [[noreturn,__gnu__::__cold__,__gnu__::__noinline__]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810
--- Comment #3 from cqwrteur ---
(In reply to Jonathan Wakely from comment #2)
> Specifically, the suggested implementation is:
>
> template
> [[noreturn,__gnu__::__cold__,__gnu__::__noinline__]]
> inline void __my_glibcxx_constexpr_assert() n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105865
--- Comment #2 from Alec ---
(In reply to Alec from comment #1)
> It also works when trying to use a template helper outside of the constructor
> See the example here https://godbolt.org/z/3raenhnjr
A regular static_cast placed where the templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105865
--- Comment #1 from Alec ---
It also works when trying to use a template helper outside of the constructor
See the example here https://godbolt.org/z/3raenhnjr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #9 from Jonathan Wakely ---
(In reply to Kevin Hendricks from comment #3)
> I thought the C++ spec said that static initialization is done in two
> phases. global (extern cost) variable are always initialized in the order
> they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #8 from Jonathan Wakely ---
(In reply to Kevin Hendricks from comment #7)
> It kind of flies in the face of how g++ without -flto worked over the long
> term (and clang++ and even the microsoft compiler) but ...
No it doesn't. It wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #7 from Kevin Hendricks ---
It kind of flies in the face of how g++ without -flto worked over the long term
(and clang++ and even the microsoft compiler) but ...
Thank you for taking the time to explain things.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #6 from Andrew Pinski ---
(In reply to Kevin Hendricks from comment #3)
> I thought the C++ spec said that static initialization is done in two
> phases. global (extern cost) variable are always initialized in the order
> they are d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #5 from Kevin Hendricks ---
It was declared in sg_constants.h as:
extern const std::string MAIN_EXTERN_CONST_STRING;
But why was its global nature lost:
Based on nm output:
./no_lto_test:1210 t
_GLOBAL__sub_I__Z24MAIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #3 from Kevin Hendricks ---
I thought the C++ spec said that static initialization is done in two phases.
global (extern cost) variable are always initialized in the order they are
declared first and local (dynamic) static initializ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
Roger Sayle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877
--- Comment #1 from H.J. Lu ---
"strip -g" removed .gnu.debuglto_.debug_info sections. Should LTO remove the
references of stripped debug info? Or should "strip -g" keep LTO debug info?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105872
--- Comment #1 from Matthias Zimmerman ---
analyzing Node_Id = 2490 system.ads:81:48 N_ENTRY_CALL_STATEMENT
This should not be N_ENTRY_CALL_STATEMENT, an earlier pass should have
converted it into N_OP_MINUS
(grep " 2490 " on gcc-12.1)
anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #2 from Kevin Hendricks ---
Created attachment 53102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53102&action=edit
zip archive with simple test case and build script
To make testing easier I have attached a small zip with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877
Bug ID: 105877
Summary: GNU strip breaks -flto -g .o files
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
--- Comment #1 from Andrew Pinski ---
Initialization order between translation units is unspecified so I think this
is OK.
Also there is a dup of this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105876
Bug ID: 105876
Summary: use of -flto with g++ changes global extern const
std::string initialization in unexpected manner
Product: gcc
Version: 12.1.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105873
--- Comment #3 from Jakub Jelinek ---
Though, the first #c0 message is different, that is from
static void
gomp_thread_start (struct gomp_thread_pool *pool)
{
struct gomp_thread *thr = gomp_thread ();
gomp_sem_init (&thr->release, 0);
thr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93485
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105873
--- Comment #2 from Jakub Jelinek ---
int retry = 100;
do
{
if (retry-- == 0)
{
/* It really shouldn't happen that barriers get out of sync, but
if they do then this will loop until they realign, so w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105875
Bug ID: 105875
Summary: Toggling an atomic_bool is inefficient
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
Bug ID: 105874
Summary: [13 Regression] Incorrect codegen and ICE since
g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810
--- Comment #2 from Jonathan Wakely ---
Specifically, the suggested implementation is:
template
[[noreturn,__gnu__::__cold__,__gnu__::__noinline__]]
inline void __my_glibcxx_constexpr_assert() noexcept
{
constexpr __glibcxxassertiontype __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105873
--- Comment #1 from Jakub Jelinek ---
I think it might be interesting to see which private values are used when:
#pragma omp declare target
int
foo (void)
{
int result = 0;
void **buf = __builtin_malloc (8192 * 2 * sizeof (void *));
#pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105873
Bug ID: 105873
Summary: [amdgcn][OpenMP] task reductions fail with "team
master not responding; slave thread aborting"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871
--- Comment #3 from Jakub Jelinek ---
Created attachment 53099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53099&action=edit
gcc13-pr105871.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105872
Bug ID: 105872
Summary: GNAT Bug Box compiling spark_xrefs.adb
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
--- Comment #4 from Andreas Schwab ---
The situation hasn't changed in the last 7 months.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:2005b9b888eeac078f2524b1521885f4b5453894
commit r13-1006-g2005b9b888eeac078f2524b1521885f4b5453894
Author: Richard Earnshaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
--- Comment #3 from JUN SHA ---
(In reply to Andreas Schwab from comment #1)
> There is actually a total of two tests that PASS:
> c-c++-common/asan/strncpy-overflow-1.c and
> c-c++-common/asan/strlen-overflow-1.c.
I spent a few hours debugging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-06-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
nu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1003-20220607102453-gcef3f69c2f4-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220607 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> I think the fix we want is simply:
I meant to say the fix we want for __absu. We still need to detect overflow
separately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
--- Comment #2 from JUN SHA ---
(In reply to Andreas Schwab from comment #1)
> There is actually a total of two tests that PASS:
> c-c++-common/asan/strncpy-overflow-1.c and
> c-c++-common/asan/strlen-overflow-1.c.
I spent a few hours debugging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #2 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:cd22395457f063824c839fd1c0077d15d3dccd6d
commit r13-1005-gcd22395457f063824c839fd1c0077d15d3dccd6d
Author: liuhongt
Date: Mon Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105747
--- Comment #6 from David Binderman ---
Here are the results from -ftime-report, with the 0.0% lines removed:
Time variable usr sys wall
GGC
phase opt and generate : 19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
Andreas Schwab changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105869
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856
--- Comment #5 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c00e1e3aa5ae62a991d105d309061d12f6a8764f
commit r13-1004-gc00e1e3aa5ae62a991d105d309061d12f6a8764f
Author: Roger Sayle
Date: Tue J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853
--- Comment #4 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c00e1e3aa5ae62a991d105d309061d12f6a8764f
commit r13-1004-gc00e1e3aa5ae62a991d105d309061d12f6a8764f
Author: Roger Sayle
Date: Tue J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54346
--- Comment #4 from Hongtao.liu ---
Now more x86 shuffle instrinsics are folded into gimple VEC_PERM_EXPR, I guess
we need some Gimple-level pattern match to simplify successive vec_perm_expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
Bug ID: 105870
Summary: Asan cannot work correctly for RISC-V GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105747
--- Comment #5 from David Binderman ---
Created attachment 53097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53097&action=edit
C source code
This source code file takes something over ten minutes,
with compiler flags -fno-var-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105869
Bug ID: 105869
Summary: Use of this inside a lambda not inside a non-static
method gives an interesting message
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105836
--- Comment #1 from Tobias Burnus ---
Created attachment 53096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53096&action=edit
Testcase (patch) for libgomp/testsuite/libgomp.fortran/allocate-1.f90
[Testcase patch]
Attached is the patch I
72 matches
Mail list logo
