https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
Bug ID: 114870
Summary: stddef.h problem with -Wsystem-headers on Fedora 40
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
--- Comment #4 from m.cencora at gmail dot com ---
I've stumbled upon a related error when trying to export std::vector after
inclusion of in GMF:
module;
namespace std
{
class vector;
namespace __format {
using std::vector;
}
}
export module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050&action=edit
patch proposal
Here is the patch I propose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #15 from Jakub Jelinek ---
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
suggests that it is a UB if all the bits for a single element aren't the same
(i.e. false is all 0s, true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Attachment #58043|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #7 from Andrew Pinski ---
Patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650085.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650084.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #16 from Christophe Lyon ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
Andrew Pinski changed:
What|Removed |Added
Summary|std::atomic::compare_exc |[13/14/15 Regression]
|h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #4 from Peter Dimov ---
This
https://raw.githubusercontent.com/boostorg/uuid/feature/gcc_pr_114865/test/test_gcc_pr114865.cpp
exhibits the problem for me on GCC 13/14. I'm only seeing the hang with
-std=c++11 -m32 in the CI run bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #5 from Andrew Pinski ---
Created attachment 58053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58053&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #6 from Andrew Pinski ---
(In reply to Peter Dimov from comment #4)
> but I believe it's independent of standard level and address model.
No it is dependent on the standard level. C++11 fails but C++14, C++17 and
C++20 all pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #7 from Andrew Pinski ---
The problem is only with auto atomic variables. Looks like the padding there is
not being zeroed for -std=c++11 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #8 from Peter Dimov ---
(In reply to Andrew Pinski from comment #6)
> No it is dependent on the standard level. C++11 fails but C++14, C++17 and
> C++20 all pass.
That's interesting because I see basically no difference in the gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #9 from Peter Dimov ---
Oh, my mistake. C++14 does mov QWORD, and C++11 does mov WORD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
Andrew Pinski changed:
What|Removed |Added
Summary|[13/14/15 Regression] |[13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #11 from Peter Dimov ---
So, basically, C++14 and above initialize the padding of
```
std::atomic state{{ 0, 0x }};
```
in `main` to zero, which masks the problem in `generate`. (The problem in
`generate` still exists becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #12 from Andrew Pinski ---
(In reply to Peter Dimov from comment #11)
> So, basically, C++14 and above initialize the padding of
>
> ```
> std::atomic state{{ 0, 0x }};
> ```
>
> in `main` to zero, which masks the problem i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #13 from Peter Dimov ---
(In reply to Andrew Pinski from comment #10)
> #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
> __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #15 from Jerry DeLisle ---
(In reply to Matt Thompson from comment #14)
> Never mind. I'll send attachment to Jerry offline. It's too big for here.
Got it. It works quite well for our purposes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
--- Comment #7 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:140124ad54eef88ca87909f63aedc8aaeacefc65
commit r15-11-g140124ad54eef88ca87909f63aedc8aaeacefc65
Author: Xi Ruoyao
Date: Fri Apr 26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:3e04b6f6ba568e6183e8aa8223d4156234503843
commit r14-10142-g3e04b6f6ba568e6183e8aa8223d4156234503843
Author: Xi Ruoyao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Xi Ruoyao changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
101 - 126 of 126 matches
Mail list logo
