[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #9 from Pekka S ---
Any updates on this? --disable-analyzer does not unfortunately resolve this
problem as analyzer objects are always built and ENABLE_ANALYZER does not gate
any header files that would be required by the code.
The quick and dirty way of resolving this problem would be:
hashval_t hash () const
{
-return (binding_key::impl_hash () ^ (long)m_region);
+return (binding_key::impl_hash () ^ (long)(uintptr_t)m_region);
}
But perhaps that would simply suppress a valid error if the implementation
expects that no precision is lost.
[Bug c/93132] bogus `attribute((access))' warning when size-index is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93132
--- Comment #2 from Pekka S ---
As the patch is pretty trivial, I think it's easiest if you simply make the
appropriate changes, including incrementing the atoi() values. I did mention
in the last paragraph that not incrementing the 1-based indexes is a bit
misleading, so I guess this confirms that :-)
By the way, at least with AArch64 on C++ front-end the test case contributed by
you causes an ICE. I did already notice this earlier on my tests -- complex,
i.e. normal, files with prototyped access attributes are fine, but on simple
cases with very little code they ICE. This sounds a bit fishy to me (perhaps
the cause is found somewhere else). Are you able to reproduce this? Shall I
make a separate PR?
$ g++ -S -Wall -xc++ pr93132.c
pr93132.c:12:29: internal compiler error: canonical types differ for identical
types 'void(void*, int, int, int, int)' and 'void(void*, int, int, int, int)'
12 | f (void*, int, int, int, int); // { dg-warning "attribute
'access\\\(read_only, 1, 3\\\)' mismatch positional argument values 3 and 5" }
I do not have the backtrace available to be included here, but if I recall
correctly it wasn't anywhere near `c-attribs.c' code.
[Bug c/93132] New: bogus `attribute((access))' warning when size-index is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93132 Bug ID: 93132 Summary: bogus `attribute((access))' warning when size-index is specified Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 47580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47580&action=edit Use formatted attribute specifier `attrspec', not the input one Hi. `append_access_attrs' at `gcc/c-family/c-attribs.c' has a slight issue when it tries to match the size-index parameter: 3973 if (n2 && strncmp (attrstr + n1 + 1, pos + n1, n2)) The problem is that `attrstr' is the input / human-readable attribute string (e.g. `attribute((__read_only__, 1, 2))' and not the formatted one (denoted by `attrspec', e.g. `r0\01'). The corresponding warning message has this typo, too, and it uses `atoi (attrstr + n1 + 1)' while it should of course use `attrspec'. Attached a proposed patch. As a side note, it's possibly a bit misleading that the values in the warning message are one less than the given inputs; Perhaps `atoi()' values should be incremented by one.
[Bug middle-end/92153] New: [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 Bug ID: 92153 Summary: [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: GC Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: i686-w64-mingw32 x86_64-w64-mingw32 Target: aarch64-none-elf Hi. I suspect that the previous ggc-page commit [1] accidentally created an use-after-free, which will be triggered at least on *-w64-mingw32 hosts. On my systems this is super easy to reproduce when using C++ frontend, C frontend requires orders of magnitude larger input files. I tried disabling any security measures (such as ASLR) and tried this on multiple Windows 10 1903 machines. (The input is not important here, just that release_pages() is called.) $ cat ggc-pagecrash.cpp #include $ g++ -O0 ggc-pagecrash.cpp -wrapper gdb,--args Thread 1 received signal SIGSEGV, Segmentation fault. release_pages () at /gcc/gcc/ggc-page.c:1159 (gdb) bt #0 release_pages () at /gcc/gcc/ggc-page.c:1159 #1 release_pages () at /gcc/gcc/ggc-page.c:1016 #2 0x0069f113 in ggc_collect () at /gcc/gcc/ggc-page.c:2205 (The rest of the stack frames omitted.) gcc/ggc-page.c: 1158 free (g->allocation); 1159 n1 += g->alloc_size; // <-- this line was added I'm not claiming that I would fully understand the page allocation code, but I presume `g->allocation' does reference itself to some extent. At least this is what I'm seeing on one of my systems: 862 allocation = XNEWVEC (char, alloc_size); // allocation=0x1e49b040, alloc_size=2101247, ... 893 group->allocation = allocation; // group=0x1e49bfe0, and, indeed, later on: 1158 free (g->allocation); // allocation=0x1e49b040, 1159 n1 += g->alloc_size; // g=0x1e49bfe0 -> SIGSEGV. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=474507cc277c500e580003f45ed91130adc0bde3
[Bug target/91833] [10 Regression] [AArch64] LSE atomics depends on glibc specific sys/auxv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833 --- Comment #3 from Pekka S --- Well, actually I'm also using newlib (always using the latest trunk). It's configured and built as usual (not patching anything), but I don't think I've ever seen inhibit_libc being defined -- I did notice it in the lse-init.c, but I thought (as it wasn't being set for my configuration) it perhaps gates some other features. I'm not targetting any particular OS but using a bare bones setup. I've been using my build scripts for quite some time now (a couple of years?) and it's been all good so far; I use a couple of different newlib configurations (nano and non-nano). Perhaps I need to study what inhibit_libc affects, should it cause some other unwanted behaviour for my purposes, and where it would be detected in the configure scripts. Or, simply supply a stub sys/auxv.h and carry on.
[Bug bootstrap/91834] New: [AArch64] LSE atomics, ILP32 warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834 Bug ID: 91834 Summary: [AArch64] LSE atomics, ILP32 warnings Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. libgcc/config/aarch64/lse.S produces the following warning when doing an ILP32 build, which is then repeated multiple times. This is because w(tmp1) and s(tmp1) point to the same register. I presume the warning itself is not bogus. libgcc/config/aarch64/lse.S:230: Warning: unpredictable: identical transfer and status registers --`stlxr w17,w17,[x1] 101 #define w(N)glue2(w, N) 102 #if SIZE < 8 103 # define s(N) w(N) 104 #else 105 # define s(N) x(N) 106 #endif ... 230 STXRw(tmp1), s(tmp1), [x1] I did not study the LSE code further, as I don't know if this feature is expected to work with ILP32 (as in perhaps not scheduled for release).
[Bug bootstrap/91833] New: [AArch64] LSE atomics depends on glibc specific sys/auxv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833 Bug ID: 91833 Summary: [AArch64] LSE atomics depends on glibc specific sys/auxv.h Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. libgcc/config/aarch64/lse-init.c includes (in order to determine hardware features). As that is a glibc specific header, its presence should be checked. If the header is not provided by the used (target) libc implementation, bootstrapping will fail.
[Bug c++/91644] New: [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644
Bug ID: 91644
Summary: [C++20] constinit segfaults inside templated functions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Created attachment 46804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46804&action=edit
constinit test cases
Hi.
Reading P1143R2 my understanding is that the constinit initialization should be
also possible inside a function scope. If I'm mistaken, it should be
diagnosted and rejected. Nonetheless, it currently segfaults the compiler, if
the function happens to be templated, so it needs some adjustment anyway:
template < typename T >
static void function() {
static __constinit auto value = 0;
}
Attached a few test cases.
[Bug driver/91352] New: Jobserver detection uses fcntl, which is not available on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91352 Bug ID: 91352 Summary: Jobserver detection uses fcntl, which is not available on mingw-w64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. driver::detect_jobserver() et. al. now use fcntl() and `F_GETFD' to determine status of a jobserver. However, this implementation unfortunately breaks mingw-w64 cross compiler builds, as fcntl() is not available on MinGW. While `fcntl.h' exists, and is properly detected by the configure script, it misses many of the POSIX file control options. Perhaps a similar check that is currently done for `F_SETLKW' should be also done for `F_GETFD'.
[Bug gcov-profile/90831] New: libgcc/libgcov-merge.c: conflicting __gcov_merge_single prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90831 Bug ID: 90831 Summary: libgcc/libgcov-merge.c: conflicting __gcov_merge_single prototype Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi CC: marxin at gcc dot gnu.org Target Milestone: --- Hi. A recent libgcov commit [1] that changed __gcov_merge_single function signatures unfortunately did not change it for all occurrances at libgcc/libgcov-merge.c: If inhibit_libc is defined, an old protype is still used for a stub function (on line 37), causing build to fail. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1a15313ca9be716c4116835bd0367ed05661a776
[Bug target/90588] New: [AArch64] SVE2 flag patch omits aarch64-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588 Bug ID: 90588 Summary: [AArch64] SVE2 flag patch omits aarch64-protos.h Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. AArch64 SVE2 flag patch (commit 33af5a3270d6c9abaf5c05040a89e41130cbd5ca) does not update `gcc/config/aarch64/aarch64-protos.h' (still uses unsigned long, not uint64_t), leading to compile errors. Maybe these changes are already done, but weren't included in the commit by a mistake?
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Pekka S changed: What|Removed |Added CC||p...@gcc-bugzilla.mail.kaps ||i.fi --- Comment #3 from Pekka S --- Created attachment 46384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46384&action=edit _Pragma tests These all yield different results, the first two won't compile but fail on different lines, which is a bit strange, as the preprocessor output doesn't appear to change (e.g. if only doing -E). The last one compiles, but obviously just because it omits the pragmas. GCC10 and GCC7 behave both the same with this test setup, so I suspect this is a long standing feature and/or issue. gcc -Wall -Wextra -c pragma.c gcc -Wall -Wextra -save-temps -c pragma.c gcc -Wall -Wextra -save-temps -DNOPRAGMA -c pragma.c
[Bug c++/89966] New: [9 Regression] non-type template argument rejects sizeof operator result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89966
Bug ID: 89966
Summary: [9 Regression] non-type template argument rejects
sizeof operator result
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Build: 9.0.1 20190404
Hi.
This has appeared within the last four weeks or so. It seems that not all
operators are affected as e.g. alignof(...) works just fine in the same
context. Maybe this has something do with the sizeof(...) internals rather
than non-type template parameters / arguments?
$ cat ntta__sizeof.cpp
template < auto a0 >
void f0() { }
void f0_call() { f0< sizeof(int) >(); }
$ g++.exe -Wall -Wextra -std=c++17 -fconcepts -c ntta__sizeof.cpp
ntta__sizeof.cpp: In function 'void f0_call()':
ntta__sizeof.cpp:3:36: error: no matching function for call to 'f0()'
3 | void f0_call() { f0< sizeof(int) >(); }
|^
ntta__sizeof.cpp:2:6: note: candidate: 'template void f0()'
2 | void f0() { }
| ^~
ntta__sizeof.cpp:2:6: note: template argument deduction/substitution failed:
ntta__sizeof.cpp: In substitution of 'template void f0() [with auto a0
= sizeof (int)]':
ntta__sizeof.cpp:3:36: required from here
ntta__sizeof.cpp:3:36: error: integral expression 'sizeof (int)' is not
constant
3 | void f0_call() { f0< sizeof(int) >(); }
|^
ntta__sizeof.cpp:3:36: error: trying to instantiate 'template void
f0()'
[Bug driver/88883] New: [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Bug ID: 3 Summary: [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-w64-mingw32 Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. It appears that when trying to build an x86_64-w64-mingw32 cross compiler targetting AArch64 the build fails at generated `gcc/options-save.c' due to narrowing conversion (using the latest trunk). This has likely something to do with the latest branch protection patches. The generated code looks like this (generated by `gcc/optc-save-gen.awk'): if (ptr->x_aarch64_branch_protection_string) fprintf (file, "%*s%s (%#lx)\n", indent, "", "aarch64_branch_protection_string", (unsigned long)ptr->x_aarch64_branch_protection_string); And this will cause something like: options-save.c::mm: error: cast from 'const char*' to 'long unsigned int' loses precision [-fpermissive] (unsigned long)ptr->x_aarch64_branch_protection_string); I'm not sure who is the real culprit here. Should the generated options saving code handle narrowing conversions better, or, as the above cast is only done for any option that does not fall under char, short, int, enum or /string/ types is this caused by a mishap when selecting the proper type for aarch64_branch_protection_string (at aarch64.opt)?
[Bug c++/82930] New: [C++17/AArch64] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82930 Bug ID: 82930 Summary: [C++17/AArch64] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 42572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42572&action=edit The test case that triggers `internal compiler error: in is_normal_capture_proxy, at cp/lambda.c:288' Hi. This could be related to others ICEs with structured bindings, but the thrown internal compiler error is at a different location and couldn't find anyone else having hit this particular spot. Attached a test case. Running it with (pretty much) the latest trunk (2017-11-09) currently gives: $ aarch64-none-elf-g++.exe -Wall -Wextra -c --std=gnu++17 ice_is_normal_capture_proxy.cpp ice_is_normal_capture_proxy.cpp: In lambda function: ice_is_normal_capture_proxy.cpp:17:8: internal compiler error: in is_normal_capture_proxy, at cp/lambda.c:288 eat(left); Any lambda (capturing or not) with an auto typed parameter will fail, if any of the structured binding result is used. It doesn't matter if the auto typed argument is actually used or, or whether or not the the code at lambda call site would actually compile, e.g. trying to call the lambda without any arguments. The test case compiles just fine, if the auto type is replaced with some other type, say an int (-DNO_AUTO_ARG).
[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 --- Comment #1 from Pekka S --- Created attachment 41359 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41359&action=edit trips __has_include_next. must be placed under last-include-dir/
[Bug preprocessor/80755] New: __has_include_next: internal compiler error: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 Bug ID: 80755 Summary: __has_include_next: internal compiler error: NULL directory in find_file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 41358 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41358&action=edit pulls last-include-dir/has_include_next Hi. __has_include_next gets confused, if it's called within a file that was included in the very last include directory. Every GCC release since at least 4.9 is affected. Note, the -idirafter is not culprit here. It's simply used to push the `last-include-dir' as the last include directory in order to easily reproduce this error. This problem does not occur, should there be any directory after that in the search paths. $ cat has_include_next.c #include $ cat last-include-dir/has_include_next #if __has_include_next() // doesn't matter if exists #endif $ gcc -E -idirafter last-include-dir has_include_next.c In file included from has_include_next.c:1:0: last-include-dir/has_include_next:1:33: error: no include path in which to search for anyfile #if __has_include_next() // doesn't matter if exists ^ cc1.exe: internal compiler error: NULL directory in find_file
[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 --- Comment #1 from Pekka S --- Created attachment 41357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41357&action=edit __has_include_next testcase on a non-existent file
[Bug preprocessor/80753] New: __has_include and __has_include_next taints subsequent I/O errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 Bug ID: 80753 Summary: __has_include and __has_include_next taints subsequent I/O errors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 41356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41356&action=edit __has_include testcase on a non-existent file Hi. It seems that whenever __has_include or __has_include_next is used, if the header file is non-existent (i.e. reading it would cause an I/O error) any subsequent #include on the same file will not fail, but error messages are silently tainted and preprocessing continues as if nothing happened. I tried pretty much every release since GCC 4.9 (up until the latest trunk), and they all behave the same. I couldn't find any information suggesting that this behaviour is to be expected and at least Clang (3.9) does not share this behaviour. $ cat has-include.c has-include-next.c #if __has_include() # error ".." #endif #include #if __has_include_next() # error ".." #endif #include $ gcc -E has-include.c has-include-next.c && echo ok # 1 "has-include.c" # 1 "" # 1 "" # 1 "has-include.c" # 1 "has-include-next.c" # 1 "" # 1 "" # 1 "has-include-next.c" ok
[Bug middle-end/79209] [5/6/7 Regression] AArch64: Inconsistent packed volatile bitfield accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79209 --- Comment #5 from Pekka S --- It's true what you quoted, but on the other hand the current behaviour does not produce code that will not fault -- it will indeed fault. I see the rationale behind the packed attribute applied to a structure (say, the attached structure has a default alignment of 4) so the compiler may generate access that is narrower (or has a smaller alignment) that what it would be normally be (at least with strict alignment) for whatever reason. However, bitfields are not marked volatile and -fstrict-volatile-bitfield is not used just for nothing. So when it says "it may not be possible to access the field with a single read or write [...]" I don't why it wouldn't be possible to use access that has a greater alignment requirement (on a strict aligment platform -- although it's actually run-time configurable on AArch64) than what the structure has with the packed attribute (reduced to the minimum, i.e. 1) set. Now, it could be argued, that with the packed attribute one could still force narrower volatile bitfield accesses if -fstrict-volatile-bitfield is used (I can't think of any reason why one would, but still), but currently even that is not possible as the accesses are not consistent. Also, what is the most misleading in this case is that -fstrict-volatile-bitfield "should use a single access of the width of the field's type" and I guess everyone agrees that packed attribute has nothing to do with width of the field's type, at least with attached structure and alike. So, perhaps inheritably by language design width and alignment are used somewhat interchangeably, even though they are not. Maybe this falls a bit inside the undefined behaviour land, but again, a warning message would suffice, if the behaviour is not going to be changed to inform the user that his mileage may vary.
[Bug c++/79209] New: AArch64: Inconsistent packed volatile bitfield accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79209
Bug ID: 79209
Summary: AArch64: Inconsistent packed volatile bitfield
accesses
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Created attachment 40571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40571&action=edit
Packed volatile bitfield testcase for both C and C++.
Hi.
It seems that volatile bitfield structures with the packed attribute set (that
are not accompanied with an aligned attribute) are accessed quite
inconsistently. The instruction used to access the volatile bitfield depends on
the optimization level, the bitfield width and the the value itself.
Moreover, -fstrict-volatile-bitfields seems to have no particular effect on
this matter (e.g. only a temporary register used to access field was changed).
Yes, noticed that there was a note regarding packed fields in the manual, but
perhaps I expected it to only cover some rare special cases.
Consider the following structure and function:
struct __attribute__((packed)) S0
{
unsigned volatile int y : 1;
unsigned volatile int x : 2;
unsigned volatile int z : 29;
}
volatile struct S0 * fn();
When updating the structure GCC generally prefers ldr w/str w (word) pair,
which is to be expected. However, based on the value being written GCC may
access the structure using ldrb w/strb w (byte) pair; usually if structure
access is not inlined and and/orr instruction is chosen based on the value
being written. Of course, should the underlying hardware only support word
access byte access will of couse fail -- hence the volatile bitfield in the
first place.
With both packed and aligned attributes set everything works as expected. I
guess the packed bitfields have been somewhat difficult thing to define and
agreed on, so a warning message (and a documentation entry explaining it) would
be just fine. Certainly could be just that I'm wrong, but as this was a tad
difficult to spot I'd still prefer it any day of the week.
Tested using GCC 6.2, 6.3 and 7.0.1 (trunk) and they all produce pratically
identical results. Both C and C++ frontends share this same mishap or feature.
aarch64-none-elf-gcc -Wall -Wextra -mabi=lp64 -fstrict-volatile-bitfields
-fno-exceptions -xc++ {-O0,-Og,-O1,-O2,-O3} -S packed-volatile-bitfield.in -o -
