[Bug c++/64236] [c++11] last alignas overrides stricter on a class definition

2020-12-05 Thread hahnjo at hahnjo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64236

Jonas Hahnfeld  changed:

   What|Removed |Added

 CC||hahnjo at hahnjo dot de

--- Comment #6 from Jonas Hahnfeld  ---
Still there in 10.2.0:

 $ cat alignas-multiple.cpp 
struct alignas(4) alignas(8) A { };
struct alignas(8) alignas(4) B { };

static_assert(alignof(A) == 8, "should have strictest alignment");
static_assert(alignof(B) == 8, "should have strictest alignment");
 $ g++ -c alignas-multiple.cpp 
alignas-multiple.cpp:5:26: error: static assertion failed: should have
strictest alignment
5 | static_assert(alignof(B) == 8, "should have strictest alignment");
  |   ~~~^~~~
 $ clang++ -c alignas-multiple.cpp
 $ echo $?
0

[Bug c++/108008] New: Compiler mis-optimization with posix_memalign

2022-12-07 Thread hahnjo at hahnjo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008

Bug ID: 108008
   Summary: Compiler mis-optimization with posix_memalign
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hahnjo at hahnjo dot de
  Target Milestone: ---

Created attachment 54033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54033&action=edit
init.cpp

Consider the attached example, reduced from some real code, and also available
on Compiler Explorer: https://godbolt.org/z/x4Gsjo7rT

The expectation is that sameZ[i] = true if zPlanes[i] == zPlanes[i + 1] which
should be the case for i = 1. However, when compiling the code with GCC 11.2.0
or 12.2.0 and -std=c++17 -O3, the output is sameZ = 0 for all three iterations
of the second loop. The problem disappears when changing anything in the
slightest manner: compiling with -O2, using -std=gnu++17, using a different
allocation function, commenting out one of the other two statements in the
first loop, using the unconditional assignment to sameZ[i], or removing the
exit(1).

Could this be a bug in the optimizer?