[Bug driver/93371] New: -ffile-prefix-map ignored with assembly files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93371 Bug ID: 93371 Summary: -ffile-prefix-map ignored with assembly files Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: comexk at gmail dot com Target Milestone: --- When using the GCC frontend to invoke GNU as, GCC passes through -fdebug-prefix-map (as --debug-prefix-map), but ignores -ffile-prefix-map. -ffile-prefix-map is supposed to be "equivalent to specifying all the individual -f*-prefix-map options." Most likely, GCC should be changed to pass --debug-prefix-map to as when the driver is passed -ffile-prefix-map (specifically in the definition of ASM_MAP in gcc/gcc.c). An alternative might be to add a --file-prefix-map option to GNU as and pass that instead; however, the only other type of prefix map is -fmacro-prefix-map, and that doesn't apply to raw as.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #24 from comexk at gmail dot com --- > All that's needed for that is an extension to provide a compile-time > constant value to a pointer, not to allow arbitrary reinterpret_casts in > constexpr. Well, there aren't that many things that reinterpret_cast can do. Casting pointers to different pointer types would be useful, but using such pointers is normally undefined behavior anyway. The exception is accessing byte representations using `char *` pointers. Supporting that in constexpr context *would* be a major feature, but it doesn't need to be allowed just because the cast itself is allowed. On the other hand, C++20 is adding an alternate way to manipulate byte representations in constexpr context, std::bit_cast. (It's non-constexpr when the types involved contain unions or pointers, so it can't be used directly in place of reinterpret_cast.) Most of the work that would be needed to support access-through-`char *` as an extension needs to be done anyway for std::bit_cast; on the other hand, its existence reduces the need for an extension. Regardless, it would be nice to lift the pointer restriction on std::bit_cast as an extension.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 comexk at gmail dot com changed: What|Removed |Added CC||comexk at gmail dot com --- Comment #3 from comexk at gmail dot com 2011-02-26 23:25:36 UTC --- I was able to get gcc to compile, and compile and run a trivial Go program on OS X with the attached patch. Since I know little about gcc, the patch is just a hack, but maybe it can help. The issues it addresses are: - some of the stuff that mksysinfo.sh generates doesn't compile. - The frontend hardcodes ".go_export" both in the C++ code and in the argument to objcopy, but Darwin wants both a segment and section name. - A lot of code relies on asm() for symbol names, but Darwin wants an underscore at the beginning (hardcode the underscore; obviously not a good plan). - SIGRTMIN is not defined (use SIGUSR1/2). - xnu doesn't support sem_init() (use pthreads). - the compiler seems to want an explicit -o with -c, but compiler_c_o in libtool somehow gets defined as no. - syscall.Sysctl isn't defined (I didn't bother to fix this but just commented out the only use). - a typo in libgo/runtime/go-new-map.c which is probably unrelated and belongs in another bug. GCC version: gcc-4.6-20110219 System: Mac OS X 10.6.6 (with MacPorts installed) Configuration: ./configure --prefix=/opt/gccgo --with-boot-ldflags="/opt/local/lib/libiconv.dylib /usr/lib/libiconv.dylib" --disable-bootstrap --with-ppl=/opt/local --with-cloog=/opt/local --with-mpfr=/opt/local --enable-gold=no --enable-ld=no --enable-languages=c,c++,go LDFLAGS="/opt/local/lib/libiconv.dylib /usr/lib/libiconv.dylib"
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #4 from comexk at gmail dot com 2011-02-26 23:28:09 UTC --- Created attachment 23482 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23482 hacky patch that should be split up
[Bug go/47910] New: typo in __go_map_next_prime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47910 Summary: typo in __go_map_next_prime Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: com...@gmail.com On line 88 of libgo/runtime/go-new-map.c, mid = (low + high / 2); should probably be mid = (low + high) / 2;
[Bug c++/87377] New: error with generic lambda accessing static field through argument within return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87377
Bug ID: 87377
Summary: error with generic lambda accessing static field
through argument within return type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: comexk at gmail dot com
Target Milestone: ---
…that's a mouthful. Here's the code:
template
struct const_val {
static constexpr auto val = _val;
};
int main() {
auto lambda = [](auto i) -> const_val { while (1); };
lambda(const_val<5>());
}
Currently, GCC trunk rejects this:
% /tmp/gcct/bin/g++ b.cpp -std=c++2a
b.cpp: In function ‘int main()’:
b.cpp:6:48: error: template argument 1 is invalid
6 | auto lambda = [](auto i) -> const_val { while (1); };
|
However, Clang accepts it.
I think this is a bug in GCC, because GCC does accept i.val as a constant
expression within the function body; for example, the example compiles if the
definition of 'lambda' is changed to:
auto lambda = [](auto i) {
const_val c;
while (1);
};
It also accepts this:
auto lambda = [](auto i) -> const_val { while (1); };
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 comexk at gmail dot com changed: What|Removed |Added CC||comexk at gmail dot com --- Comment #16 from comexk at gmail dot com --- IMHO it would be very useful to have an extension to force the compiler to accept these casts, and anything else that GCC is capable of constant-evaluating but the standard overly-conservatively rejects.
[Bug tree-optimization/87609] New: miscompilation with restrict and loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609
Bug ID: 87609
Summary: miscompilation with restrict and loop
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: comexk at gmail dot com
Target Milestone: ---
Test program below. Compiled at -O0, it outputs "7 10"; at -O3, it outputs "10
7". Removing the restrict qualifier on the arguments to copy() avoids the
issue, but copy() is never called with a == b, so there shouldn't be any
undefined behavior.
Tested with revision 7497874053f (current master), host and target
x86_64-apple-darwin18.0.0, installed using Homebrew.
--
#include
#include
#include
__attribute__((always_inline))
static inline void copy(int *restrict a, int *restrict b) {
assert(a != b);
*b = *a;
*a = 7;
}
__attribute__((noinline))
void floppy(int mat[static 2], size_t idxs[static 3]) {
for (int i = 0; i < 3; i++) {
copy(&mat[i%2], &mat[idxs[i]]);
}
}
int main() {
int mat[2] = {10, 20};
size_t idxs[3] = {1, 0, 1};
floppy(mat, idxs);
printf("%d %d\n", mat[0], mat[1]);
}
--
(For reference, I found this while investigating a similar bug in LLVM:
https://bugs.llvm.org/show_bug.cgi?id=39282)
[Bug c++/66268] New: struct { volatile int x; } should not be trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66268
Bug ID: 66268
Summary: struct { volatile int x; } should not be trivially
copyable
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: comexk at gmail dot com
Target Milestone: ---
According to the C++14 standard, a struct containing volatile fields shouldn't
be trivially copyable. 9.6 states:
> A trivially copyable class is a class that:
> — has no non-trivial copy constructors (12.8),
and 12.8.12 states:
> A copy/move constructor for class X is trivial if it is not user-provided,
> its parameter-type-list is equivalent to the parameter-type-list of an
> implicit declaration, and if
[..]
> — class X has no non-static data members of volatile-qualified type, and
GCC disagrees:
#include
#include
int main() {
struct foo { volatile int x; };
std::cout << std::is_trivially_copyable::value << std::endl;
}
/tmp % g++-5 --version
g++-5 (Homebrew gcc5 5.1.0) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/tmp % g++-5 -std=c++14 -o test test.cpp && ./test
1
[Bug libstdc++/111077] New: atomic_ref compare_exchange_strong doesn't properly ignore padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Bug ID: 111077
Summary: atomic_ref compare_exchange_strong doesn't properly
ignore padding bits
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: comexk at gmail dot com
Target Milestone: ---
C++20 requires that the functions `std::atomic::compare_exchange_strong` and
`std::atomic_ref::compare_exchange_strong` ignore any padding bits that
exist in T. libstdc++ implements this by relying on the invariant that
`std::atomic` values in memory always have zeroed padding bits. All methods
of `std::atomic` that store values to memory (including the constructor)
zero the padding bits first. Then, `std::atomic::compare_exchange_strong`
zeroes the padding bits of the `expected` value, allowing it to assume that the
native atomic compare-exchange won't fail due to padding bits.
However, this doesn't work correctly for `std::atomic_ref`. All methods of
`std::atomic_ref` that store to memory do zero the padding bits. But what
about the initial value of the object, before the first atomic_ref pointing to
it was created? That value could be anything.
As a result, this code (compiled with -std=c++20) incorrectly prints 0, even
though the only difference between `value` and `expected` is in a padding byte:
#include
#include
int main() {
struct HasPadding { char a; short b; };
HasPadding value = {};
((char *)&value)[1] = 0x42; // update padding byte
HasPadding expected = {};
printf("%d\n",
std::atomic_ref(value).compare_exchange_strong(
expected, expected));
}
This could be fixed by reimplementing
`std::atomic_ref::compare_exchange_strong` to use a loop, as in this
pseudocode:
bool compare_exchange_strong(std::atomic_ref ref, T& expected, T
desired) {
T orig = expected;
while (1) {
if (ref.compare_exchange_weak_including_padding(expected, desired))
{
return true;
}
if (!equal_ignoring_padding(orig, expected)) {
return false;
}
}
}
[See also:
https://github.com/rust-lang/unsafe-code-guidelines/issues/449#issuecomment-1677985851,
which has a comparison of different compilers.]
