https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114688
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114688
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591#c13 is talking about this
exact thing ...
So this might be expected for x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #14 from Andrew Pinski ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Hongtao Liu from comment #12)
> > short a;
> > short c;
> > short d;
> > void
> > foo (short b, short f)
> > {
> > c = b + a;
> > d = f + a;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #15 from Hongtao Liu ---
> I don't see this as problematic. IIRC, there was a discussion in the past
> that a couple (two?) memory accesses from the same location close to each
> other can be faster (so, -O2, not -Os) than preloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #16 from Hongtao Liu ---
>
> 4952 /* See if a MEM has already been loaded with a widening operation;
> 4953 if it has, we can use a subreg of that. Many CISC machines
> 4954 also have such operations, but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cb46aca0a07355abf2f0b04f52087bca8f848524
commit r14-9910-gcb46aca0a07355abf2f0b04f52087bca8f848524
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #5 from Paweł Bylica ---
(In reply to Martin Jambor from comment #4)
> In this testcase all (well, both) functions referenced from the array
> are semantically equivalent which is recognized by ICF but making it
> be able to pass thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #20 from Jakub Jelinek ---
(In reply to Hongtao Liu from comment #19)
> (In reply to Jakub Jelinek from comment #17)
> > Both of the posted patches are incorrect, this needs to be fixed in
> > asan_emit_stack_protection, account for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Bug ID: 114689
Summary: [14 Regression] libgcc/config/m68k/fpgnulib.c:305:
Suspicious coding ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114681
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:52b63100b1eda433120e726d4e8f8dfca6fc94fa
commit r14-9911-g52b63100b1eda433120e726d4e8f8dfca6fc94fa
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114681
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c7e8a8d814229fd6fc4c16c2452f15dddc613479
commit r14-9912-gc7e8a8d814229fd6fc4c16c2452f15dddc613479
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #21 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:467898d513e602f5b5fc4183052217d7e6d6e8ab
commit r14-9913-g467898d513e602f5b5fc4183052217d7e6d6e8ab
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #6 from Martin Jambor ---
(In reply to Paweł Bylica from comment #5)
> (In reply to Martin Jambor from comment #4)
> > In this testcase all (well, both) functions referenced from the array
> > are semantically equivalent which is rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #7 from Paweł Bylica ---
(In reply to Martin Jambor from comment #6)
> (In reply to Paweł Bylica from comment #5)
> > (In reply to Martin Jambor from comment #4)
> > > In this testcase all (well, both) functions referenced from the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|[11/12/13/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114690
Bug ID: 114690
Summary: OpenMP 'indirect' clause: dynamic image
loading/unloading
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114690
--- Comment #1 from Thomas Schwinge ---
I suggest that in the short term, we at least add a safeguard in the
'GOMP_OFFLOAD_load_image's to error out if 'GOMP_INDIRECT_ADDR_MAP' has already
been set (that should address (a), right?), and in the
'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Bug ID: 114691
Summary: [11/12/13/14 Regression] Bogus ignoring loop
annotation warning
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #18 from Jakub Jelinek ---
The P1 bug has been fixed, I've moved the rest to PR114691.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Bug 114691 depends on bug 114409, which changed state.
Bug 114409 Summary: [14 Regression] ICE after adding novector pragmas (internal
compiler error: in tsubst_expr, at cp/pt.cc:21794) since
r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8
h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Richard Biener changed:
What|Removed |Added
Target||m68k
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #57890|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #5 from Jonathan Wakely ---
I think we should just do this:
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline constexpr memory_ord
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #6 from Jonathan Wakely ---
It's also a mostly-harmless ABI change for C++17 down, because the underlying
type without -fshort-enums changes from implicitly being chosen as unsigned
int, to explicitly being specified as int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Bug ID: 114692
Summary: [14 Regression] Symbol versioning problem in GCC 14
libstdc++.so.6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
GLIBCXX_3.4.32 {
_ZSt21ios_base_library_initv;
_ZNSt7__cxx1112basic_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #2 from Jakub Jelinek ---
Created attachment 57927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57927&action=edit
gcc14-libstdc++-baseline-updates.patch
This was what I've been preparing before noticing this issue. If we ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
> GLIBCXX_3.4.32 {
> _ZSt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #4 from Jonathan Wakely ---
This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #5 from Jonathan Wakely ---
The *shouldn't* have been added there though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #6 from Jonathan Wakely ---
r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should
have been frozen after 13.1 but it looks like I thought it was a new version
for 13.2/14.0
Then I must have thought 13.2 and 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #7 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
Oops, guess too late then for those. We'll need to consider 13.2 as a fuzzy
snapshot in betw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Bug ID: 114693
Summary: `expand` introduce redundant store facing logic
expression
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
Component|rtl-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #8 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #4)
> > This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
>
> Oops, guess too late then for those. We'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #8 from Andreas Krebbel ---
Apparently, I decided to go with a MEM_REF already for the load variant of the
builtin - vec_xl. I've to check whether there was any reason not to do this
also for vec_xst.
Making it a pointer which alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #9 from Jakub Jelinek ---
It depends on what the vec_xl*/vec_xst* documentation requires/user expect.
If the expectation is that the loads/stores should alias the scalar pointee of
the pointer type passed to those intrinsics, then
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #10 from Jakub Jelinek ---
I admit I haven't studied what exactly pytorch does there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #16 from Michael Matz ---
(In reply to Kewen Lin from comment #15)
> I agree, thanks for the comments! btw, I'm not fighting for the current
> implementation, just want to know more details why users are unable to make
> use of the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
--- Comment #2 from Jakub Jelinek ---
Saying a function is valid code in this case is difficult, claiming that a
noreturn function is pure or returns_twice is wrong, it isn't pure, nor
returns_twice, as it never returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
--- Comment #3 from Stefan Schulze Frielinghaus
---
Thanks for the pointer. I can confirm that the patch fixes this PR and also
fixes
FAIL: gcc.dg/tree-ssa/vrp-float-abs-1.c scan-tree-dump-not evrp "link_error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #9 from Jonathan Wakely ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #20 from Richard Earnshaw ---
Created attachment 57928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928&action=edit
fully preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
--- Comment #5 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:b262b17636e47ae969a74f16e86ccb00678d5e88
commit r14-9916-gb262b17636e47ae969a74f16e86ccb00678d5e88
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Bug ID: 114694
Summary: dependent-name alias type accepted in elaborated type
specifier within a template
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1defe743aeb19532f6d6f4cab37e10f11467abd8
commit r14-9917-g1defe743aeb19532f6d6f4cab37e10f11467abd8
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #22 from Richard Earnshaw ---
(Previous analysis is based on gcc-13 branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #23 from Richard Earnshaw ---
#0 ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1 0x01768173 in indirect_ref_may_alias_decl_p (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #11 from Andreas Krebbel ---
The documentation of vec_xl and vec_xst doesn't seem to mention anything
special with regard to that. So I understand the memory is only accessed
through pointers which are compatible to the ones used whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90390
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
Bug ID: 114695
Summary: Template argument deduction and defaulted template
template parameters
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #15 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Jonathan Wakely from comment #10)
> > If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then
> > it needs to be documented at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #6 f
ression algorithms: zlib zstd
gcc version 14.0.1 20240411 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #24 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with
>
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114697
Bug ID: 114697
Summary: [DR 233] references in user defined conversions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Bug ID: 114698
Summary: dcfldd produces wrong sha256 sum on ppc64le and -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Known to work||11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110216
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 110216, which changed state.
Bug 110216 Summary: tuple_size requirements for structured binding has not been
updated after DR 2386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110216
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Component|target |ipa
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #3 from Andrew Pinski ---
uint8_t buffer[SHA256_BLOCK_LENGTH];
W256 = (sha2_word32*)context->buffer;
This is starting to smell like the code is violating strict aliasing rules ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Andrew Pinski changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #5 from Andrew Pinski ---
Specifically
https://github.com/archiecobbs/libnbcompat/commit/864c1cf42c2c605636008626f171caf6410421cb
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #6 from Andrew Pinski ---
Note this implementation of sha2.c is shared all over the place it seems and
has this known issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #7 from Andrew Pinski ---
See https://github.com/archiecobbs/libnbcompat/issues/4 for the full analysis
of the issue with sha2.c and even mentions it is shared with many projects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #8 from Peter Bergner ---
(In reply to Andrew Pinski from comment #6)
> Note this implementation of sha2.c is shared all over the place it seems and
> has this known issue ...
(In reply to Andrew Pinski from comment #4)
> (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> There might be a dup somewhere ...
PR 93816 is definitely related but it is not a dup since that has no dependent
types but it does have templates being involve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #57354|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Andrew Pinski changed:
What|Removed |Added
Component|target |driver
--- Comment #16 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #21 from Tamar Christina ---
Created attachment 57932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57932&action=edit
loop.c
attached reduced testcase that reproduces the issue and also checks the buffer
position and copied v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
Bug ID: 114699
Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
so libraries crash when dlclosed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #1 from Richard W.M. Jones ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works
I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #2 from Richard W.M. Jones ---
This was the stack trace of the crashing thread with gcc-go:
Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0 0x7ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1 0x000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #3 from Richard W.M. Jones ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time. Using
nodelete avoids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #22 from Tamar Christina ---
note that due to the secondary exit the actual full vector iteration count is 8
scalar elements at VF=4 == 2.
And it's this boundary condition where we fail, since ceil (8/4) == 2. any
other value would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101019
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114697
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFIRM
1 - 100 of 119 matches
Mail list logo
