https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
--- Comment #3 from hanwei (K) ---
Yeap, press return too soon.
Code like:
#include
#pragma pack(1)
char a_global[2] = {0,0};
int g_int[3] = {1, 2, 4};
char b_global[2] = {0, 0};
struct A {
char c;
long long a;
int i;
};
#prag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103909
accelerator0099 at gmail dot com changed:
What|Removed |Added
CC||accelerator0099 at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104384
accelerator0099 at gmail dot com changed:
What|Removed |Added
CC||accelerator0099 at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107288
accelerator0099 at gmail dot com changed:
What|Removed |Added
CC||accelerator0099 at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
--- Comment #5 from Axel Ehrich ---
Thank you for the explanation. This resolves the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #7 from Andrew Pinski ---
(In reply to YunQiang Su from comment #6)
> With some test on some CPUs, in fact, the lacking of `sll` won't make
> troubles to us.
> It seems that most of MIPS64 CPUs can process it well as expected.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #6 from YunQiang Su ---
With some test on some CPUs, in fact, the lacking of `sll` won't make troubles
to us.
It seems that most of MIPS64 CPUs can process it well as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #4 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:7d5d2b879ae7636ca118fb4f3a08b22705cdeacb
commit r15-171-g7d5d2b879ae7636ca118fb4f3a08b22705cdeacb
Author: YunQiang Su
Date: Mon Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
--- Comment #2 from Andrew Pinski ---
Also DATA_ALIGNMENT (and LOCAL_ALIGNMENT) does not conflict with `pragma pack`.
The documentation says
https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html :
```
that change the maximum alignmen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114943
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114957
Bug ID: 114957
Summary: pragma pack is not in the concept index for the manual
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956
Bug ID: 114956
Summary: Segmentation fault with -fsanitize=address
-fsanitize=null -O2 when attribute no_sanitize_address
is enabled
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955
Bug ID: 114955
Summary: marco DATA_ALIGNMENT may conflict with pragma pack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #15 from Luke Dalessandro ---
(In reply to Jonathan Wakely from comment #5)
>
> IMO the ideal solution is for GCC to stop using whether a function is inline
> as an optimisation hint. Then we wouldn't need some extra GCC-specific wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #14 from Chris Elrod ---
To me, an "inline" function is one that the compiler inlines.
It just happens that the `inline` keyword also means both comdat semantics, and
possibly hiding the symbol to make it internal (-fvisibility-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #13 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #12)
> There's nothing fake about them, they are definitely inline functions as far
> as the language rules. But in some cases we don't want the compiler to use
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482
--- Comment #9 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Eric Gallager from comment #6)
> > Another reason this warning might be wanted: name mangling and demangling of
> > global constructors has been bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114954
Bug ID: 114954
Summary: [modules] ICE in write_class_def with templated union
type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #20 from Andrew Pinski ---
New patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650757.html
It was simplier than I had expected too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114953
Bug ID: 114953
Summary: libstdc++'s 30_threads/semaphore/try_acquire_posix.cc
can sometimes fail (while running under qemu)
Product: gcc
Version: 15.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952
--- Comment #1 from Andrew Pinski ---
Most likely GCC does not know errno is non-zero after the call to elf_open and
checking `fd < 0`.
Adding:
if (ret == 0) __builtin_unreachable();
After the assignment of `ret = -errono;` fixes the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952
Bug ID: 114952
Summary: False positive -Wmaybe-uninitialized starting at -O3
in libbpf
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951
Andrew Pinski changed:
What|Removed |Added
Known to work||14.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951
Bug ID: 114951
Summary: Incorrect documentation link emitted for warning
options ending in =
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
--- Comment #3 from Uroš Bizjak ---
R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #12 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:21e7aa5f3ea44ca2fef8deb8788edffc04901b5c
commit r15-168-g21e7aa5f3ea44ca2fef8deb8788edffc04901b5c
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O3|[14/15 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114950
Bug ID: 114950
Summary: [modules] ICE in binding_cmp when merging friend
functions in partitions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114949
Bug ID: 114949
Summary: Missing function return count in JSON format
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gco
LTO compression algorithms: zlib
gcc version 15.0.0 20240505 (experimental) (GCC)
[523] %
[523] % gcctk -O3 -fno-tree-ccp -fno-tree-ch small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
34 matches
Mail list logo
