[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

2022-04-01 Thread lists at coryfields dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

Cory Fields  changed:

   What|Removed |Added

 CC||lists at coryfields dot com

--- Comment #33 from Cory Fields  ---
Adding another +1. Still present in 10.3.0.

Bitcoin Core's sha2 code uses avx2 when possible. We ran into this bug when
bumping our toolchain:
https://github.com/bitcoin/bitcoin/pull/24736

and opted to take Debian's patch:
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/blob/master/debian/patches/vmov-alignment.patch

It's unfortunate that the best and most common advice for using avx2 with
gcc/mingw is to use a patched compiler. Might it be possible to accept Debian's
patch upstream?

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

2017-05-31 Thread lists at coryfields dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593

Cory Fields  changed:

   What|Removed |Added

 CC||lists at coryfields dot com

--- Comment #9 from Cory Fields  ---
I assume based on the milestone that this will be backported to 7.2?

Boost's aligned_storage is affected as well, causing floods of warnings from
several of its containers (multi_index, at least) which use it.

[Bug c++/61039] New: Using a constexpr's address as a template variable produces an unnecessary warning

2014-05-02 Thread lists at coryfields dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61039

Bug ID: 61039
   Summary: Using a constexpr's address as a template variable
produces an unnecessary warning
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lists at coryfields dot com

Tangentially related to bug #51440 and #52036. Present in 4.7-4.9.

Using the address of a non-type constexpr variable in the global namespace (or
specified namespace) as a template parameter produces the following warning:

test.h:14:8: warning: 'child1' has a base 'charptrbase<((const char*)(&
chararray))>' whose type uses the anonymous namespace
 struct child1 : public charptrbase

Marking the constexpr as extern eliminates the warning, but I don't believe
that should be necessary for c++11. Use of the constant itself rather than the
address does not show the issue.

Preprocessed source for an offending example is very short, so I'll paste below
rather than attaching. The int parameter gives no warning, but the int* and
const char* do.

Clang compiles and gives the following warning when -Wc++98-compat is enabled,
which leads me to believe that this is a subtle c++11 gcc bug:

./test.h:14:36: warning: non-type template argument referring to object
'chararray' with internal linkage is incompatible with C++98 [-Wc++98-compat]
struct child1 : public charptrbase

preprocessed source follows:
--

# 1 "test.cpp"
# 1 "/home/cory/dev//"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 30 "/usr/include/stdc-predef.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/predefs.h" 1 3 4
# 31 "/usr/include/stdc-predef.h" 2 3 4
# 1 "" 2
# 1 "test.cpp"
# 1 "test.h" 1
constexpr const int intval = 0;
constexpr const char chararray[] = "test";

template
struct charptrbase {};

template
struct intptrbase {};

template
struct intbase {};


struct child1 : public charptrbase
{};

struct child2 : public intptrbase<&intval>
{};

struct child3 : public intbase
{};
# 2 "test.cpp" 2

int main()
{
  child2 foo;
  (void)foo;
  return 0;
}