[Bug tree-optimization/107919] Possibly false-positive "maybe-uninitialized" with GCC 12 on complex variant-variant-tuple-unique_ptr types

[freddie_chopin at op dot pl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919

--- Comment #1 from Freddie Chopin  ---
More possibly imporant notes:
1. The warning appears only with -O1 or -O2, with 0, s, g or 3 the warning is
gone.
2. Adding -fsanitize=undefined to compiler invocation makes the warning go away
as well - no terminal output is produced in that case.

[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning

[freddie_chopin at op dot pl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138

Freddie Chopin  changed:

   What|Removed |Added

 CC||freddie_chopin at op dot pl

--- Comment #8 from Marco Clemencic  ---
That explains it then, thanks for the info.

I admit I like the idea a lot. I'm just surprised that we do get warnings from
the C++ standard library in some perfectly reasonable code...

Now I have to decide what to do in my code. Probably I'll have to selectively
suppress the warning, which is something I hate.

But the warning is not issued in -O0 builds, which I believe means the code is
correct by itself, but I have the feeling the warning gets checked after the
optimizer refactored the code taking into account invariants already checked
and at that point the "maybe-uninitialized" checker gets confused. If this is
the case we can argue if it is the intended behavior or a bug in the way this
new feature has been implemented.

--- Comment #9 from Freddie Chopin  ---
Possibly related/duplicate #107919

[Bug c++/107919] New: Possibly false-positive "maybe-uninitialized" with GCC 12 on complex variant-variant-tuple-unique_ptr types

[freddie_chopin at op dot pl via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919

Bug ID: 107919
   Summary: Possibly false-positive "maybe-uninitialized" with GCC
12 on complex variant-variant-tuple-unique_ptr types
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Following code gives no warning with GCC 11.3 and earlier versions:

-- 8< -- 8< -- 8< -- 8< -- 8< -- 8< --

#include 
#include 

using Event = std::variant>>, int,
char>;

void do_something(void* storage)
{
Event event {};
auto& swappedValue = *reinterpret_cast(storage);
std::swap(event, swappedValue);
}

-- 8< -- 8< -- 8< -- 8< -- 8< -- 8< --

When compiled with GCC 12.1 or newer it reports a (possibly false-positive)
maybe-uninitialized warning that is so long, that it is hard to comprehend (;

-- 8< -- 8< -- 8< -- 8< -- 8< -- 8< --

$ g++ -std=c++17 -c -O2 warn.cpp -Wall -Wextra
In file included from /usr/include/c++/12.2.0/bits/unique_ptr.h:36,
 from /usr/include/c++/12.2.0/memory:76,
 from warn.cpp:1:
In constructor ‘constexpr std::_Tuple_impl<_Idx, _Head, _Tail
...>::_Tuple_impl(std::_Tuple_impl<_Idx, _Head, _Tail ...>&&) [with long
unsigned int _Idx = 0; _Head = int*; _Tail = {std::default_delete}]’,
inlined from ‘constexpr std::tuple<_T1, _T2>::tuple(std::tuple<_T1, _T2>&&)
[with _T1 = int*; _T2 = std::default_delete]’ at
/usr/include/c++/12.2.0/tuple:1090:17,
inlined from ‘std::__uniq_ptr_impl<_Tp,
_Dp>::__uniq_ptr_impl(std::__uniq_ptr_impl<_Tp, _Dp>&&) [with _Tp = int; _Dp =
std::default_delete]’ at /usr/include/c++/12.2.0/bits/unique_ptr.h:177:9,
inlined from ‘std::__uniq_ptr_data<_Tp, _Dp, , 
>::__uniq_ptr_data(std::__uniq_ptr_data<_Tp, _Dp, ,  >&&)
[with _Tp = int; _Dp = std::default_delete; bool  = true; bool
 = true]’ at /usr/include/c++/12.2.0/bits/unique_ptr.h:234:7,
inlined from ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(std::unique_ptr<_Tp,
_Dp>&&) [with _Tp = int; _Dp = std::default_delete]’ at
/usr/include/c++/12.2.0/bits/unique_ptr.h:358:7,
inlined from ‘std::_Head_base<_Idx, _Head,
false>::_Head_base(std::_Head_base<_Idx, _Head, false>&&) [with long unsigned
int _Idx = 0; _Head = std::unique_ptr]’ at
/usr/include/c++/12.2.0/tuple:196:17,
inlined from ‘constexpr std::_Tuple_impl<_Idx,
_Head>::_Tuple_impl(std::_Tuple_impl<_Idx, _Head>&&) [with long unsigned int
_Idx = 0; _Head = std::unique_ptr]’ at
/usr/include/c++/12.2.0/tuple:456:41,
inlined from ‘constexpr std::tuple< 
>::tuple(std::tuple<  >&&) [with _Elements =
{std::unique_ptr >}]’ at
/usr/include/c++/12.2.0/tuple:756:17,
inlined from ‘constexpr std::__detail::__variant::_Uninitialized<_Type,
false>::_Uninitialized(std::in_place_index_t<0>, _Args&& ...) [with _Args =
{std::tuple > >}; _Type =
std::tuple > >]’ at
/usr/include/c++/12.2.0/variant:283:4,
inlined from ‘constexpr std::__detail::__variant::_Variadic_union<_First,
_Rest ...>::_Variadic_union(std::in_place_index_t<0>, _Args&& ...) [with _Args
= {std::tuple > >}; _First =
std::tuple > >; _Rest = {}]’ at
/usr/include/c++/12.2.0/variant:385:4,
inlined from ‘void std::_Construct(_Tp*, _Args&& ...) [with _Tp =
__detail::__variant::_Variadic_union
> > >; _Args = {const in_place_index_t<0>&, tuple > >}]’ at
/usr/include/c++/12.2.0/bits/stl_construct.h:119:7,
inlined from ‘std::__detail::__variant::_Move_ctor_base > >
>::_Move_ctor_base(std::__detail::__variant::_Move_ctor_base > >
>&&):: mutable [with auto:4 =
std::tuple > >; auto:5 =
std::integral_constant]’ at
/usr/include/c++/12.2.0/variant:605:23,
inlined from ‘constexpr _Res std::__invoke_impl(__invoke_other, _Fn&&,
_Args&& ...) [with _Res = void; _Fn =
__detail::__variant::_Move_ctor_base > >
>::_Move_ctor_base(std::__detail::__variant::_Move_ctor_base > >
>&&)::; _Args = {tuple > >, integral_constant}]’ at
/usr/include/c++/12.2.0/bits/invoke.h:61:36,
inlined from ‘constexpr typename std::__invoke_result<_Functor,
_ArgTypes>::type std::__invoke(_Callable&&, _Args&& ...) [with _Callable =
__detail::__variant::_Move_ctor_base > >
>::_Move_ctor_base(std::__detail::__variant::_Move_ctor_base > >
>&&)::; _Args = {tuple > >, integral_constant}]’ at
/usr/include/c++/12.2.0/bits/invoke.h:96:40,
inlined from ‘static constexpr decltype(auto)
std::__detail::__va

[Bug other/86890] GCC 8.2.0 fails to build with isl 0.20

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86890

--- Comment #2 from Freddie Chopin  ---
Prerequisites docs say "isl Library version 0.15 or later". Configure script
also accepts 0.20 just fine.

BTW - 0.19 builds and works OK.

[Bug other/86890] New: GCC 8.2.0 fails to build with isl 0.20

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86890

Bug ID: 86890
   Summary: GCC 8.2.0 fails to build with isl 0.20
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

When trying to build GCC 8.2.0 with isl 0.20, I see a lot (at least a few
dozens) of errors about undeclared functions, like:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -I. -I.
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/.
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../include
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libcpp/include
-I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/gmp-6.1.2/include
-I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/mpfr-4.0.1/include
-I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/mpc-1.1.0/include
 -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libdecnumber
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libbacktrace
-I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/isl-0.20/include
-I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/zlib-1.2.11/include
-pipe  -o graphite-isl-ast-to-gimple.o -MT graphite-isl-ast-to-gimple.o -MMD
-MP -MF ./.deps/graphite-isl-ast-to-gimple.TPo
/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c
/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c:
In function ‘void ivs_params_clear(ivs_params&)’:
/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c:83:7:
error: ‘isl_id_free’ was not declared in this scope
   isl_id_free (it->first);
   ^~~
/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c:83:7:
note: suggested alternative: ‘isl_aff_free’
   isl_id_free (it->first);
   ^~~
   isl_aff_free

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

This seems like some header include problems or something like that, as there
definitely is a isl_id_free() function in
/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/isl-0.20/include/isl/id.h,
which is available in the search path.

[Bug libstdc++/85886] New: std::atomic<> doesn't have value_type and difference_type

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85886

Bug ID: 85886
   Summary: std::atomic<> doesn't have value_type and
difference_type
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

According to https://en.cppreference.com/w/cpp/atomic/atomic std::atomic<>
should contain value_type and difference_type, which is not the case in GCC's
libstdc++.

Use case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#include 
#include 
#include 

void f()
{
std::atomic_int8_t referenceCount_;
assert(referenceCount_ !=
std::numeric_limits<std::decay<decltype(referenceCount_)>::type::value_type>::max());
++referenceCount_;
}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug c++/85739] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739

Freddie Chopin  changed:

   What|Removed |Added

  Attachment #44111|0   |1
is obsolete||

--- Comment #2 from Freddie Chopin  ---
Created attachment 44116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44116=edit
reduced and generic test case for gcc 8.1.0

I attach reduced test case for gcc 8.1.0. Interestingly today I cannot
reproduce the error for previous versions of gcc, which means that either I
just got confused yesterday or the triggering code is a bit different. So for
now let's ignore previous versions and focus on gcc 8.1.0.

Using the test case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ --version
g++ (GCC) 8.1.0
Copyright (C) 2018 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.

$ g++ -c Scheduler-8.cpp -std=c++14

$ g++ -c Scheduler-8.cpp -std=c++17
Scheduler-8.cpp: In instantiation of ‘class B’:
Scheduler-8.cpp:29:20:   required from here
Scheduler-8.cpp:3:47: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3057
 template  class B { using e = ptrdiff_t; };
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug c++/85739] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739

--- Comment #1 from Freddie Chopin  ---
I'm currently in the process of reducing the test case with the wonderful tool
that I've found yesterday - C-Reduce (; I hope that I'll be able to upload
something short and generic (not requiring arm-none-eabi) within a few hours.

[Bug c++/85739] New: internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739

Bug ID: 85739
   Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:3057
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Created attachment 44111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44111=edit
preprocessed source code

Attached preprocessed source code.

Trying to build it:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-g++ -fno-use-cxa-atexit -fno-rtti -fno-exceptions
-mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2
-ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -std=gnu++17 -o
Scheduler.cpp.o -c Scheduler.ii
In file included from
../include/distortos/internal/scheduler/ThreadListNode.hpp:15,
 from
../include/distortos/internal/scheduler/ThreadControlBlock.hpp:17,
 from ../include/distortos/internal/scheduler/Scheduler.hpp:15,
 from ../source/scheduler/Scheduler.cpp:12:
../include/estd/IntrusiveList.hpp: In instantiation of 'class
estd::IntrusiveListConstIterator<distortos::internal::ThreadListNode,
::internal::ThreadListNode::threadListNode,
distortos::internal::ThreadControlBlock>':
../source/scheduler/Scheduler.cpp:345:31:   required from here
../include/estd/IntrusiveList.hpp:650:1: internal compiler error: in
finish_member_declaration, at cp/semantics.c:3057
 {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
$ arm-none-eabi-g++ --version
arm-none-eabi-g++ (bleeding-edge-toolchain) 8.1.0
Copyright (C) 2018 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.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

The exact same thing happens for gcc 7.3.0 and 6.3.0. There is no error when
using `-std=gnu++11` or `-std=gnu++14`. Whether or not GNU extensions are
enabled makes no difference.

Let me know if I should try to narrow the problem down, as the preprocessed
test case is indeed a bit huge.

[Bug target/85606] New: Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85606

Bug ID: 85606
   Summary: Assembly file generated for ARM Cortex-M0 should not
specify `.arch armv6-m` at all or use `.arch armv6s-m`
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

This issue is inspired by following bug report for GAS -
https://sourceware.org/bugzilla/show_bug.cgi?id=23126

Following test case works perfectly fine for GCC 5, 6 and 7, however it fails
with GCC 8.0.1 20180427:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat svc.cpp 
__attribute__ ((naked))
int supervisorCall(int (& function)(int, int, int, int), const int argument1,
const int argument2, const int argument3,
const int argument4)
{
asm volatile
(
"   mov r12, r0 \n"
"   ldr r0, [sp]\n"
"   svc 0   \n"
"   \n"
"   bx  lr  \n"
);

__builtin_unreachable();

// suppress warnings
(void)function;
(void)argument1;
(void)argument2;
(void)argument3;
(void)argument4;
}
$ arm-none-eabi-g++ -c svc.cpp -mcpu=cortex-m0 -save-temps
svc.s: Assembler messages:
svc.s:31: Error: SVC is not permitted on this architecture
$ diff -u svc-7.s svc.s 
--- svc-7.s 2018-05-01 20:14:09.031910734 +0200
+++ svc.s   2018-05-01 20:16:36.751143427 +0200
@@ -12,6 +12,7 @@
.text
.align  1
.global _Z14supervisorCallRFiE
+   .arch armv6-m
.syntax unified
.code   16
.thumb_func
@@ -37,4 +38,4 @@
.cantunwind
.fnend
.size   _Z14supervisorCallRFiE,
.-_Z14supervisorCallRFiE
-   .ident  "GCC: (bleeding-edge-toolchain) 7.3.0"
+   .ident  "GCC: (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)"
$ cat svc.s 
.cpu cortex-m0
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "svc.cpp"
.text
.align  1
.global _Z14supervisorCallRFiE
.arch armv6-m
.syntax unified
.code   16
.thumb_func
.fpu softvfp
.type   _Z14supervisorCallRFiE, %function
_Z14supervisorCallRFiE:
.fnstart
.LFB0:
@ Naked Function: prologue and epilogue provided by programmer.
@ args = 4, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
.syntax divided
@ 12 "svc.cpp" 1
mov r12, r0 
ldr r0, [sp]
svc 0   

bx  lr  

@ 0 "" 2
.thumb
.syntax unified
.cantunwind
.fnend
.size   _Z14supervisorCallRFiE,
.-_Z14supervisorCallRFiE
.ident  "GCC: (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)"

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

(svc-7.s is a temp file generated with GCC 7.3.0)

Nick Clifton in his comment
(https://sourceware.org/bugzilla/show_bug.cgi?id=23126#c4) to the mentioned GAS
bug report suggested that GCC 8 should either specify just `.cpu` (behaviour as
in previous versions) or specify `.arch armv6s-m` instead of `.arch armv6-m`.
Personally I think the first option should be more reliable in that case,
however this is just a guess.

[Bug c++/85580] New: "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580

Bug ID: 85580
   Summary: "conflicting C language linkage declaration" warning
for variables with identical names in `extern "C"`
functions
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Here's a minimal test case executed with 8.0.1-RC-20180427 (compiled for
arm-none-eabi target, but I think the problem is not target-specific):

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat test.cpp

extern "C"
{

void f1()
{
  union some_type{
char a[2];
int b;
  } variable;
}

void f2()
{
  union some_type{
char a[2];
int b;
  } variable;
}

}

$ arm-none-eabi-gcc test.cpp -c
test.cpp: In function 'void f2()':
test.cpp:17:5: warning: conflicting C language linkage declaration
'f2()::some_type variable'
   } variable;
 ^~~~
test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
   } variable;
 ^~~~

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)
Copyright (C) 2018 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.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

For the problem to appear:
- functions with the types and variables have to be extern "C"
- the file must be C++
- there has to be both a type and a variable
- the variables must have identical names

The problem was spotted with ARM CMSIS headers, where similar pattern exists:
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L1929

Related discussion on mailing list:
https://gcc.gnu.org/ml/gcc/2018-04/msg00191.html

[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461

--- Comment #2 from Freddie Chopin  ---
Any chance there is a patch for this problem that could be merged before 7.3?

[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703

--- Comment #6 from Freddie Chopin  ---
The runtime checks are no good in deeply embedded (like a MCU)...

Anyway - would this behave the same if the values in `in[]` would NOT be known
at compile time? For example provided by user for each run of the application?
I'm trying to fully understand the problem here and this really seems wrong to
me that the compiled program behaves so crazy just because 10 lines below
there's an integer overflow...

[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703

--- Comment #4 from Freddie Chopin  ---
Would it be possible to have a warning with -Wall -Wextra when something like
that happens? I think this behaviour here is really strange and really
unexpected. In "real" programs I guess there are tons of such tiny undefined
behaviours so eliminating them is probably very hard, which would then render
-O3 option completely useless.

[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703

--- Comment #2 from Freddie Chopin  ---
Indeed, reducing the values in `in[]` makes the code behave properly. But
anyway - how does this particular (minor) issue in the code affect a seemingly
unrelated loop? After all, this loop's variable - `b1` - is never modified
apart from the loop's incrementation... I'm not saying that this example code
is perfectly valid (it was a quick and dirty test of something else), but the
behaviour observed with -O3 is really surprising.

[Bug c/83703] New: Loop termination condition ignored in -O3, works in -O2 or with smaller values

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703

Bug ID: 83703
   Summary: Loop termination condition ignored in -O3, works in
-O2 or with smaller values
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Example code:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#include 
#include 

const int32_t limit {359};

const int32_t in[]
{
  599,
  600,
  601,
  1199,
  1200,
  1201,
  1799,
  1800,
  1801,
  2599,
  2600,
};

const int32_t out[]
{
  0,
  0,
  1,
  1,
  1,
  2,
  2,
  2,
  3,
  3,
  3,
};

int main()
{
  for (int32_t b1 = -limit; b1 < limit; ++b1)
  {
for (int32_t b0 = -limit; b0 < limit; ++b0)
{
  for (int32_t a0 = -limit; a0 < limit; ++a0)
  {
if (a0 == 0)
  continue;
int fail = 0;
for (size_t i {}; i < sizeof(out) / sizeof(*out) && fail == 0; ++i)
{
  fail |= (b1 * in[i] + b0) / a0 != out[i];
}

if (fail == 0)
{
  printf("success! %i %i %i\n", (int)b1, (int)b0, (int)a0);
  return 0;
}  
  }
}
printf("fail! %i\n", (int)b1);
  }
  return 0;
}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

This code works as intended when compiled with -O2 - last iteration of the
outer loop is with b1 == 358. However when compiled with -O3, the outer's loop
condition is completely ignored - the loop passes well above the value of
`limit` and continues infinitely. Increasing the value of `limit` gives exactly
the same result.

This fails:
$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 964
fail! 965
^C
$


This works:
$ gcc -O2 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 357
fail! 358
$

When I change `limit` to 358, at -O3 there is only ONE iteration.

$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out 
fail! -358
$

When I change `limit` to 357, the program works as intended at -O3. Any value
lower and it's the same

$ gcc --version
gcc (GCC) 7.2.1 20171128
Copyright (C) 2017 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.

Tested on two PCs with Arch Linux, but both are actually mostly identical in
h/w and s/w.

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

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593

Bug ID: 80593
   Summary: GCC 7, aligned_storage and “dereferencing type-punned
pointer will break strict-aliasing rules”
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

I've posted this info to the gcc mailing list. Richard Biener suggested opening
a bug report, so here it is.

https://gcc.gnu.org/ml/gcc/2017-05/msg00013.html

Following example code is warning-free on GCC 4.9, GCC 5 and GCC 6. It is also
warning free on some older GCC 7 snapshots (like 7-20170409).

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat punning.cpp 
template
struct aligned_storage
{
  union type
{
  unsigned char __data[_Len];
  struct __attribute__((__aligned__((_Align { } __align;
};
};

aligned_storage<sizeof(int), alignof(int)>::type storage;

int main()
{
  *reinterpret_cast<int*>() = 42;
}
$ g++ -Wall -O2 -c punning.cpp 
$

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

However in the most recent GCC 7 snapshots (including both RCs), it gives a
warning about type punning:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ -Wall -O2 -c punning.cpp 
punning.cpp: In function 'int main()':
punning.cpp:15:35: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
   *reinterpret_cast<int*>() = 42;
   ^
$

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug c++/80534] [7/8 Regression] 7.1 RC - internal compiler error: in finish_member_declaration, at cp/semantics.c:2963

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534

--- Comment #9 from Freddie Chopin  ---
Patch above (applied to 7.0.1-RC-20170425) fixes the original issue which I
reported - the project builds fine and works correctly. The warnings
("dereferencing type-punned pointer will break strict-aliasing rules") are
still there, but I guess this is not related after all.

[Bug c++/80534] [7/8 Regression] 7.1 RC - internal compiler error: in finish_member_declaration, at cp/semantics.c:2963

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534

--- Comment #1 from Freddie Chopin  ---
Created attachment 41276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41276=edit
preprocessed source which causes the problem - minimal version

OK, I've managed to narrow it down to a much smaller test case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat ice.cpp 
#include 

using Storage = std::aligned_storage::type;
using StorageUniquePointer = std::unique_ptr;
StorageUniquePointer storageUniquePointer_ {new Storage[1]};

$ arm-none-eabi-g++ -c ice.cpp 
In file included from
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/memory:80:0,
 from ice.cpp:1:
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:
In instantiation of 'class std::unique_ptr::type [],
std::default_delete::type []> >':
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:470:2:
  required from 'std::unique_ptr<_Tp [], _Dp>::unique_ptr(_Up) [with _Up =
std::aligned_storage<4>::type*; _Vp =
std::default_delete::type []>; 
= void;  = bool; _Tp = std::aligned_storage<4>::type;
_Dp = std::default_delete::type []>]'
ice.cpp:5:59:   required from here
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:398:5:
internal compiler error: in finish_member_declaration, at cp/semantics.c:2963
 {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

I'm attaching preprocessed source again.

The problem goes away in these situations:
- not using array as the type of std::unique_ptr;
- using anything "simple" as the "Storage" type (for example just an "int")
instead of std::aligned_storage;
- not initializing the object or initializing it with nullptr;

[Bug c++/80534] New: 7.1 RC - internal compiler error: in finish_member_declaration, at cp/semantics.c:2963

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534

Bug ID: 80534
   Summary: 7.1 RC - internal compiler error: in
finish_member_declaration, at cp/semantics.c:2963
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 41275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41275=edit
preprocessed source which causes the problem

When building my C++ project with the GCC 7.1 RC I get following compiler
error:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -g -ggdb3 -mcpu=cortex-m4
-mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions  -I../../output/include
-I../../include -I../../source/architecture/ARM/ARMv6-M-ARMv7-M/include  -c
lowLevelInitialization.cpp -o
../../output/source/scheduler/lowLevelInitialization.o
In file included from
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/memory:80:0,
 from
../../include/distortos/internal/synchronization/SignalInformationQueue.hpp:19,
 from
../../include/distortos/SignalInformationQueueWrapper.hpp:15,
 from ../../include/distortos/StaticSignalsReceiver.hpp:15,
 from ../../include/distortos/StaticThread.hpp:16,
 from lowLevelInitialization.cpp:15:
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:
In instantiation of 'class std::unique_ptr<std::aligned_storage<12, 4>::type
[], void (&)(std::aligned_storage<12, 4>::type*)>':
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:588:16:
  required from 'std::unique_ptr<_Tp [], _Dp>::pointer std::unique_ptr<_Tp [],
_Dp>::get() const [with _Tp = std::aligned_storage<12, 4>::type; _Dp = void
(&)(std::aligned_storage<12, 4>::type*); std::unique_ptr<_Tp [], _Dp>::pointer
= std::aligned_storage<12, 4>::type*]'
../../include/distortos/internal/synchronization/SignalsCatcherControlBlock.hpp:186:67:
  required from here
/home/freddie/bleeding-edge-toolchain/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi-gcc-7.0.1-RC-20170425-170426/arm-none-eabi/include/c++/7.0.1/bits/unique_ptr.h:398:5:
internal compiler error: in finish_member_declaration, at cp/semantics.c:2963
 {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

I'm attaching preprocessed source file.

Compiler version:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 7.0.1 20170425 (prerelease)
Copyright (C) 2017 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.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

There's no error with GCC 6.3 and there was no error with 7-20170409 snapshot.

Additionally - maybe this is related - I'm now seeing a few new warnings:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

warning: dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

These were also not present with the mentioned snapshot or with latest stable
version.

This problem appears on a toolchain compiled for "arm-none-eabi" target. The
toolchain was built with this script:

https://github.com/FreddieChopin/bleeding-edge-toolchain/tree/gcc-7-experimental

The problem appears in building this project:

https://github.com/DISTORTEC/distortos

Here's the travis-ci log:

https://travis-ci.org/FreddieChopin/bleeding-edge-toolchain/builds/226127050 

Please let me know whether I can give you any more information.

This problem may seem similar to #79308, but I think this is something
different - I see no ICE with GCC 6, GCC 5 or GCC 4.9 - only with the most
recent GCC 7 "RC" snapshot.

[Bug c++/80332] Warning is issued for deprecated "using" type alias of deprecated type

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80332

--- Comment #2 from Freddie Chopin  ---
Same behaviour with gcc 7.0.1 20170409.

[Bug c++/80332] New: Warning is issued for deprecated "using" type alias of deprecated type

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80332

Bug ID: 80332
   Summary: Warning is issued for deprecated "using" type alias of
deprecated type
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

There is a base type with "__attribute__ ((deprecated))". If I create an alias
with "typedef", which also has "__attribute__ ((deprecated))", no warning is
issued, which matches the official docs:

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes

However if I create a C++11 type alias with "using" keyword, which also has
"__attribute__ ((deprecated))", then the warning is issued for the line with
type alias.

I would expect that it would work the same way as deprecated "typedef", so no
warning.

Code:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

typedef int Integer __attribute__ ((deprecated));
using Using __attribute__ ((deprecated)) = Integer;
typedef Integer Typedef __attribute__ ((deprecated));

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Test:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ -c depr.cpp 
depr.cpp:2:44: warning: ‘Integer’ is deprecated [-Wdeprecated-declarations]
 using Using __attribute__ ((deprecated)) = Integer;
^~~
depr.cpp:1:13: note: declared here
 typedef int Integer __attribute__ ((deprecated));
 ^~~

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug c++/66297] [C++14] [DR 1684] constexpr non-static member functions of non-literal types

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66297

Freddie Chopin  changed:

   What|Removed |Added

 CC||freddie_chopin at op dot pl

--- Comment #5 from Freddie Chopin  ---
Any chance for merging the fix for GCC 7? It would be a pity to wait for a
fixed release for another year...

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436

--- Comment #6 from Freddie Chopin  ---
> On a newer Intel (or AMD) machine, add -march=naitve and you will
> see the same behavior.

You are right, adding that switch causes the assert to appear...

> VFMA is not just multiply and accumulate but rather fused multiply and add.
> The multiplication is done in infinite precision and then the add is done 
> in that same infinite precision and then a round happens down to double. 
> Instead of what happens with -ffp-contract=off which is not to used the 
> fused multiple add instruction which means round between the multiply and
> addition.

I've read that info already, but in my (limited) understanding subtracting two
identical numbers still gives 0 at infinite precision, no matter how you round
the result ); But I get your point - somehow after re-arranging the whole
sequence, the result got inexact (from my point of view).

Any advice how to handle this problem in this particular code? I'd prefer not
to just set "-ffp-contract=off" for my whole project, as the toolchain
libraries are compiled with contracting enabled anyway (I see A LOT of VFMA in
functions like sinf() or cosf()), so that "solution" would be partial at best.
Is there any "generic" way to write code that would allow the result to be
"correct", possibly by also allowing optimizations which don't change accuracy?

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436

--- Comment #4 from Freddie Chopin  ---
Hello Andrew and thanks for your answer.

Generally I don't care about the sequence of operations or the exact
instructions that get generated, but in this case this default behaviour
produces invalid results.

Generally the whole calculations are like this:
mx = ex - sx;
my = ey - sy;
distance = sqrtf(mx * mx + my * my) * constant;

The important thing here is that ex and sx are bitwise identical, just as ey
and sy. Thus everything above can be transformed to:

mx = x - x;
my = y - y;
distance = sqrtf(mx * mx + my * my) * constant;

and then:

mx = 0;
my = 0;
distance = sqrtf(0 * 0 + 0 * 0) * constant;

However you rearrange that, the expected result is 0 and I see no place for
"typical" floating point inaccuracies here. Let me reiterate - "startVector"
and "endVector" in my test case are bitwise identical. Yet the code produces
1.34925369e-06 at the end...

The same code compiled at -O2 for x86-64 does not assert. I don't know x86-64
assembly, but I'm pretty sure that it supports this kind of instructions.

If the results of VFMA are considered "good enough" I think that the default
value of -ffp-contract should be changed to "off" - after all
-funsafe-math-optimizations or -ffast-math are not enabled by default either.

BTW - VFMA is used also with "-std=c++11".

Thus I think that the bug is not invalid and I ask you to reconsider. Thanks in
advance!

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436

--- Comment #2 from Freddie Chopin  ---
Created attachment 40701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40701=edit
assembly dump of valid version

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436

--- Comment #1 from Freddie Chopin  ---
Created attachment 40700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40700=edit
assembly dump of invalid version

[Bug target/79436] New: [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436

Bug ID: 79436
   Summary: [ARM Cortex-M4F] VFMA used in place of subtraction
gives inexact results
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40699=edit
test case

In some very specific code paths with specific optimization compiler generates
VNEG (negate) + VFMA (multiply and accumulate) instead of VSUB + VMUL. Most
likely this is not a problem in most cases, but in the test case I attach this
leads to inexact results in a well-defined code. The variable "distance", which
is basically a length of a difference of two _IDENTICAL_ vectors multiplied by
some constant factor, is expected to be 0. "x - x" for components of each
vector gives zero. "0 * 0" gives zero. "0 + 0" gives zero. "sqrtf(0)" gives
zero. "0 * x" gives 0. These are basically all the operations in the example.
However the value of "distance" is calculated to be 1.34925369e-06 and the
assertion fails.

Several notes:

1. The code seems complicated, but if I simplify it, different sequence of
instructions is generated, and the VNEG + VFMA used instead of VSUB + VMUL is
essential to the problem. To generate slightly different sequence it's enough
to uncomment the assertion that checks equality of vectors.

2. The problem appears on -O2, -O3 and -Os. It does not appear on -O1 and -Og
(probably neither with -O0, but I did not check).

3. The problem can be observed for GCC 6.3.0 and GCC 5.3.1. With or without ARM
patches.

Exact compilation command:

arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -g -ggdb3 -mcpu=cortex-m4
-mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions -c vfma.cpp -o vfma.o

I also attach assembly output of the "invalid" version (-O2) and "valid"
version (-O1).

[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824

--- Comment #5 from Freddie Chopin  ---
Sure, more data points show that this is most likely a problem in a target
component, not in middle-end or c front-end.

[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824

Freddie Chopin  changed:

   What|Removed |Added

 CC||freddie_chopin at op dot pl

--- Comment #3 from Freddie Chopin  ---
Works fine on arm-none-eabi- on -O1, -O2, -O3:

y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
 80001e4:   4b03ldr r3, [pc, #12]   ; (80001f4 <main+0x10>)
 80001e6:   4a04ldr r2, [pc, #16]   ; (80001f8 <main+0x14>)
 80001e8:   781bldrbr3, [r3, #0]
 80001ea:   011blslsr3, r3, #4
 80001ec:   8013strhr3, [r2, #0]

However on -Os suboptimal (and actually longer) code is generated:

y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
 8008ef6:   4b75ldr r3, [pc, #468]  ; (80090cc
<main+0x1d8>)
 8008efa:   781aldrbr2, [r3, #0]
 8008efc:   eb02 03c2   add.w   r3, r2, r2, lsl #3
 8008f00:   eb03 0382   add.w   r3, r3, r2, lsl #2
 8008f04:   eb03 0342   add.w   r3, r3, r2, lsl #1
 8008f08:   4413add r3, r2
 8008f0a:   4a71ldr r2, [pc, #452]  ; (80090d0
<main+0x1dc>)
 8008f0c:   b29buxthr3, r3
 8008f0e:   8013strhr3, [r2, #0]

Similar code is generated for -Og.

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904

--- Comment #9 from Freddie Chopin  ---
Any chance for merging the fix to gcc-6 branch before gcc 6.3 would be
released?

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904

--- Comment #7 from Freddie Chopin  ---
Could this be also backported to the gcc-6 branch? I guess there will be 6.3
version (possibly before first 7.x version), so it would be nice to have this
patch there (;

[Bug c++/77907] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

--- Comment #1 from Freddie Chopin  ---
Maybe it is important to add, that it doesn't matter whether
SomeClass::someFunction() is const or not - it behaves identically in both
cases.

[Bug c++/77907] New: Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

Bug ID: 77907
   Summary: Add "const" to argument of constexpr constructor
causes the object to be left in unconstructed state
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, arm-none-eabi

Failing test case:

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
$ cat test.cpp 
struct SomeClass
{
void someFunction() {}
};

struct SomeFunctor
{
using MemberFunction = void(SomeClass::*)();

constexpr explicit SomeFunctor(const MemberFunction memberFunction) :
memberFunction_{memberFunction}
{

}

MemberFunction memberFunction_;
};

extern SomeFunctor functor;
SomeFunctor functor {::someFunction};
$ g++ test.cpp -c -O2 -std=c++11
$ objdump -SD --demangle test.o

test.o: file format elf64-x86-64


Disassembly of section .bss:

 :
...

Disassembly of section .comment:

 <.comment>:
   0:   00 47 43add%al,0x43(%rdi)
   3:   43 3a 20rex.XB cmp (%r8),%spl
   6:   28 47 4esub%al,0x4e(%rdi)
   9:   55  push   %rbp
   a:   29 20   sub%esp,(%rax)
   c:   36 2e 31 2e ss xor %ebp,%cs:(%rsi)
  10:   31 20   xor%esp,(%rax)
  12:   32 30   xor(%rax),%dh
  14:   31 36   xor%esi,(%rsi)
  16:   30 36   xor%dh,(%rsi)
  18:   30 32   xor%dh,(%rdx)
...
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

As you can see the object get's placed in .bss section and no constructor is
generated - the object will have only zeroes in the program. The thing that
causes the problem here is the "const" added to the "memberFunction" argument
of the constructor. If I remove it, then I get the properly constructed object
in .data section.

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
$ cat test.cpp 
struct SomeClass
{
void someFunction() {}
};

struct SomeFunctor
{
using MemberFunction = void(SomeClass::*)();

constexpr explicit SomeFunctor(/*const*/ MemberFunction memberFunction)
:
memberFunction_{memberFunction}
{

}

MemberFunction memberFunction_;
};

extern SomeFunctor functor;
SomeFunctor functor {::someFunction};
$ g++ test.cpp -c -O2 -std=c++11
$ objdump -SD --demangle test.o

test.o: file format elf64-x86-64


Disassembly of section .group:

 <.group>:
   0:   01 00   add%eax,(%rax)
   2:   00 00   add%al,(%rax)
   4:   06  (bad)  
   5:   00 00   add%al,(%rax)
...

Disassembly of section .data:

 :
...

Disassembly of section .text._ZN9SomeClass12someFunctionEv:

 <SomeClass::someFunction()>:
   0:   f3 c3   repz retq 

Disassembly of section .comment:

 <.comment>:
   0:   00 47 43add%al,0x43(%rdi)
   3:   43 3a 20rex.XB cmp (%r8),%spl
   6:   28 47 4esub%al,0x4e(%rdi)
   9:   55  push   %rbp
   a:   29 20   sub%esp,(%rax)
   c:   36 2e 31 2e ss xor %ebp,%cs:(%rsi)
  10:   31 20   xor%esp,(%rax)
  12:   32 30   xor(%rax),%dh
  14:   31 36   xor%esi,(%rsi)
  16:   30 36   xor%dh,(%rsi)
  18:   30 32   xor%dh,(%rdx)
...

Disassembly of section .eh_frame:

 <.eh_frame>:
   0:   14 00   adc$0x0,%al
   2:   00 00   add%al,(%rax)
   4:   00 00   add%al,(%rax)
   6:   00 00   add%al,(%rax)
   8:   01 7a 52add%edi,0x52(%rdx)
   b:   00 01   add%al,(%rcx)
   d:   78 10   js 1f <.eh_frame+0x1f>
   f:   01 1b   add%ebx,(%rbx)
  11:   0c 07   or $0x7,%al
  13:   08 90 01 00 00 14   or %dl,0x1401(%rax)
  19:   00 00   add%al,(%rax)
  1b:   00 1c 00add%bl,(%rax,%rax,1)
  1e:   00 00   add%al,(%rax)
  20:   00 00   add%al,(%rax)
  22:   00 00   add%al,(%rax)
  24:   02 00   add(%rax)

[Bug c/77904] New: [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904

Bug ID: 77904
   Summary: [ARM Cortex-M0] Frame pointer thrashes registers if
assembly statements with "sp" clobber are used
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

In some very specific cases frame pointer can thrash caller's r7 (frame
pointer) register. The following test case demonstrates the problem.

 8<  8<  8<  8<  8<  8<  8< 

$ cat test.cpp 
void removeStackFrame(const void* const savedStackPointer)
{
  __asm volatile ("MSR psp, %0\n" : : "r" (savedStackPointer) : "sp");
}
$ arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -O2 test.cpp -c
$ arm-none-eabi-objdump -S test.o 

test.o: file format elf32-littlearm


Disassembly of section .text:

 <_Z16removeStackFramePKv>:
   0:   af00add r7, sp, #0
   2:   f380 8809   msr PSP, r0
   6:   46bdmov sp, r7
   8:   4770bx  lr
   a:   46c0nop ; (mov r8, r8)

 8<  8<  8<  8<  8<  8<  8< 

As you can see in this particular function the frame pointer thrashes caller's
r7, which should be saved on stack and restored before returning. In this test
case this seems to be caused by the "sp" clobber in the assembly statement
(this particular line comes from CMSIS headers for ARM Cortex-M
microcontrollers) - if I remove this clobber, then the frame pointer is omitted
and the problem is gone, but this can hardly be considered a solution...

This is somehow specific only to ARM Cortex-M0 - selecting ARM Cortex-M4
("-mcpu=cortex-m4") causes r7 to be pushed to the stack.

This is not related to optimization level, as the same behaviour can be
observed on all optimization levels.

Using "-fomit-frame-pointer" doesn't change anything, but doing the opposite
"-fno-omit-frame-pointer" - causes r7 to be stacked.

This problem was not present on GCC 5.3.1 (at least on the version with ARM
patches) - with that version the frame pointer was omitted. Currently I'm
observing this problem on almost clean GCC 6.2.0 - the only change is the
multilib configuration.

[Bug c++/71113] Adding "const" to value in constexpr constructor places const object in .bss instead of .rodata

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71113

--- Comment #1 from Freddie Chopin  ---
BTW, I've come to the code as above from a slightly different scenario -
initially I tried using references, but it was failing (placed in RAM, not in
flash) no matter what I did. Now I think that the two problems may be related,
so one more example:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

class X
{
public:

constexpr X(int& ref) :
ref_{ref}
{

}

private:

int& ref_;
};

#define PERIPHERAL1 (int*)0x2000
const X xxx1 {*PERIPHERAL1};
int something;
const X xxx2 {something};

int main()
{

}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Test compilation:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ test.cpp && objdump -x --syms --demangle a.out | grep xxx
00600a70 l O .bss   0008  xxx1
00400658 l O .rodata0008  xxx2

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

The object with reference to "real" int is placed in .rodata, the one with the
reference to "peripheral" - in .bss.

[Bug c++/71113] New: Adding "const" to value in constexpr constructor places const object in .bss instead of .rodata

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71113

Bug ID: 71113
   Summary: Adding "const" to value in constexpr constructor
places const object in .bss instead of .rodata
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Take a look at following test case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

class X
{
public:

constexpr X(void* pointer) :
pointer_{pointer}
{

}

private:

void* pointer_;
};

#define PERIPHERAL1 (void*)0x2000
const X xxx {PERIPHERAL1};

int main()
{

}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Execute test:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ test.cpp && objdump -x --syms --demangle a.out | grep xxx
00400608 l O .rodata0008  xxx

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Everything's fine. Now just add one trivial change, which does _NOT_ change any
logic (at least in my opinion (; ). Replace:

constexpr X(void* pointer) :

with

constexpr X(void* const pointer) :

And the object is placed in .bss, not in .rodata...

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ test.cpp && objdump -x --syms --demangle a.out | grep xxx
00600a58 l O .bss   0008  xxx

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

There's no problem if an address of "real" object is used, so for example
something like this works fine in both cases:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

int something;
const X xxx {};

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

The use case may seem a bit strange, but the macro definition like the one used
in the example is used commonly in hardware headers for microcontrollers. They
usually look like this:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#define PERIPH_BASE   ((uint32_t)0x4000U)
#define APB2PERIPH_BASE   (PERIPH_BASE + 0x0001U)
#define USART1_BASE   (APB2PERIPH_BASE + 0x1000U)
#define USART1  ((USART_TypeDef *) USART1_BASE)

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

(USART_TypeDef is a typedef of an anonymous struct with layout of peripheral
registers)

The behaviour was noticed in GCC compiled for "arm-none-eabi-", version 5.3.1,
but the same thing happens in a desktop version 6.1.1 on Arch Linux.

[Bug c++/64514] [4.9/5 Regression] Error in template instantiation in GCC 4.9, works fine in GCC 4.8

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64514

--- Comment #1 from Freddie Chopin freddie_chopin at op dot pl ---
The question at stackoverflow has an answer with much simpler test-case which
also shows the problem. http://stackoverflow.com/a/27810002/157344

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

templatetypename... T
struct Functor
{
template T...
struct Inner
{};
};

template struct Functor::Inner;

int main()
{

}

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

Compiled with GCC 4.9.2:

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

$ g++ -std=c++11 test.cpp 
test.cpp: In instantiation of ‘struct Functor’:
test.cpp:9:26:   required from here
test.cpp:5:12: error: wrong number of template arguments (1, should be 0)
 struct Inner
^
test.cpp:5:12: error: provided for ‘templateclass ... T templateT
...anonymous  struct FunctorT::Inner’
test.cpp:5:12: error: wrong number of template arguments (1, should be 0)
test.cpp:5:12: error: provided for ‘templateclass ... T templateT
...anonymous  struct FunctorT::Inner’
test.cpp:9:28: error: ‘Inner’ is not a class template
 template struct Functor::Inner;
^
test.cpp:9:28: error: ‘Inner’ in ‘struct Functor’ does not name a type

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

Works fine with GCC 4.8.

The answer also suggests there might be another similar bug, possibly related
to the first one.

[Bug c++/64514] New: Error in template instantiation in GCC 4.9, works fine in GCC 4.8

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64514

Bug ID: 64514
   Summary: Error in template instantiation in GCC 4.9, works fine
in GCC 4.8
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl

The test code below works perfectly fine with GCC 4.8 (and 4.7):

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

#include type_traits

templatetypename T, T object, typename... Args
struct Functor
{
templatefloat (T::*function)(Args...), Args... args
struct Inner
{
float operator()() const
{
return (object.*function)(args...);
}
};
};

class Object
{
public:

float someFunction()
{
return {};
}

float someFunctionWithArgument(int)
{
return {};
}
};

Object object;

FunctorObject, object::InnerObject::someFunction functor1;
FunctorObject, object, int::InnerObject::someFunctionWithArgument, 1
functor2;

int main()
{

}

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

However with GCC 4.9 it fails with a rather unhelpful message at the point of
instantiation of functor1:

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

$ g++ -std=c++11 test.cpp 
test.cpp: In instantiation of ‘struct FunctorObject, (*  object)’:
test.cpp:33:24:   required from here
test.cpp:7:9: error: wrong number of template arguments (2, should be 1)
  struct Inner
 ^
test.cpp:7:9: error: provided for ‘templateclass T, T object, class ... Args
templatefloat (T::* function)(Args ...), Args ...args struct FunctorT,
object, Args::Inner’
test.cpp:7:9: error: wrong number of template arguments (2, should be 1)
test.cpp:7:9: error: provided for ‘templateclass T, T object, class ... Args
templatefloat (T::* function)(Args ...), Args ...args struct FunctorT,
object, Args::Inner’
test.cpp:33:26: error: ‘Inner’ in ‘struct FunctorObject, (*  object)’ does
not name a template type
 FunctorObject, object::InnerObject::someFunction functor1;
  ^

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 ---

If I comment the line with functor1 instantiation, everything else (functor2)
works fine.

At the stackoverflow question I asked (
http://stackoverflow.com/questions/27802404/error-in-template-instantiation-in-gcc-4-9-works-fine-in-gcc-4-8?noredirect=1#comment44015634_27802404
) it was reported that clang 3.5 and Visual Studio 2015 Preview accept this
code, while intel 14 errors out (with an unreported message) and solaris studio
12.4 crashes.

Is there something wrong with this code (which was working for me for over 2
years with older versions) or maybe this is a regression?

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #7 from Freddie Chopin freddie_chopin at op dot pl ---
Great (; Do you have some timeline? I'm not trying to rush you - I'm just
working on a project in which this feature would be beneficial, so I'm
wondering whether I should wait a bit (this particular requirement is not
top-priority) or maybe just implement the allocator the old way for now.

Thanks in advance!

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[freddie_chopin at op dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Freddie Chopin freddie_chopin at op dot pl changed:

   What|Removed |Added

 CC||freddie_chopin at op dot pl

--- Comment #5 from Freddie Chopin freddie_chopin at op dot pl ---
Any news on that bug? I just hit the same problem as the author, so I'm
wondering whether anyone's working on that or maybe I could help a little bit?

[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



--- Comment #5 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 
09:07:37 UTC ---

Yes, sorry about the fuzz with the testcase and thx for confirming.

[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



Freddie Chopin freddie_chopin at op dot pl changed:



   What|Removed |Added



 CC||freddie_chopin at op dot pl



--- Comment #7 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 
15:08:42 UTC ---

I really don't understand why Paolo Carlini is constantly removing me from the

CC list...

[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



--- Comment #9 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 
15:31:46 UTC ---

(In reply to comment #8)

 Perhaps because you are the reporter and reporter is always CCed on the PRs, 
 no

 matter if on CC or not?



If you remove me from the CC list I won't receive the comments that appear

here, and I don't mind reading them. If my mailbox gets spammed with messages

from bugzilla I'll remove myself, so no worries (;



Thx in advance for NOT-removing me again.

[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126



--- Comment #4 from Freddie Chopin freddie_chopin at op dot pl 2013-02-13 
07:29:23 UTC ---

Created attachment 29430

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29430

simple fail case



I think I have an even simplier test case, I guess it's the same problem (at

least the ICE message matches). I also think that bug 51707 is actually the

same problem.

[Bug c++/56291] New: ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



 Bug #: 56291

   Summary: ICE for C++11 in output_constructor_regular_field, at

varasm.c:4821

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: freddie_cho...@op.pl





[freddie@arch ~]$ cat file.cpp

class Base

{

public:

 constexpr Base() : v(1) {};

 int v;

};



class Derived : public Base

{

public:

 constexpr Derived() : Base() {};

 virtual void function();

};



Derived d;[freddie@arch ~]$ g++ -std=c++11 -c file.cpp

file.cpp:15:10: internal compiler error: in output_constructor_regular_field,

at varasm.c:4821

Please submit a full bug report,

with preprocessed source if appropriate.

See https://bugs.archlinux.org/ for instructions.

[freddie@arch ~]$ g++ -v

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib

--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

--with-bugurl=https://bugs.archlinux.org/

--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared

--enable-threads=posix --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch

--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id

--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check

--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default

--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu

--enable-multilib --disable-libssp --disable-build-with-cxx

--disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC) 



---



Each of the listed things makes the problem go away:

- making function() non-virtual (or removing it)

- making both or at least Derived's constructor non-constexpr

- removing the member field v from Base (along with the initializer in the

constructor)



I've tested with g++, x86_64-w64-mingw32-g++, i686-w64-mingw32-g++ (all on

Linux), arm-none-eabi-g++, mingw32-g++ (both on Windows), all the toolchains I

have are 4.7.2 and in each of them the problem is identical. I've also have the

same error with 4.6.2 arm-none-eabi-g++.



Is anything more needed? Maybe this is already fixed (and/or reported)?



Thx in advance!

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



--- Comment #2 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 
07:14:17 UTC ---

Created attachment 29421

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29421

failing test case

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291



Freddie Chopin freddie_chopin at op dot pl changed:



   What|Removed |Added



 CC||freddie_chopin at op dot pl



--- Comment #3 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 
07:26:05 UTC ---

(In reply to comment #1)

 Current mainline and 4_7-branch work for me. The weird thing is, stock 4.7.2

 also works fine for me - I think this is essentially a duplicate of c++/54253.

 Are you sure you are using a stock FSF 4.7.2?



First of all, I've just noticed that in my example code the last newline is

missing, so a very important last line (that creates the object - without it

there's no problem too) got merged with the shell prompt. To be really sure,

I'm pasting the example again:



// starts here

class Base

{

public:

 constexpr Base() : v(1) {};

 int v;

};



class Derived : public Base

{

public:

 constexpr Derived() : Base() {};

 virtual void function();

};



Derived d;

// ends here



Sorry about that thing not being clearly stated in the first message. I've also

added an attachment this time, so there's no way to miss this last line.



As for your questions and suggestions. First of all this is not related to the

bug you mentioned - all three testcases attached there work for me without a

problem (I tested like this - g++ -std=c++11 -c filename -o

output_filename), and from the description I think the problem was a

segfault, while I have a ICE report coming from gcc_assert(). Am I using a

vanilla GCC - that's a good question (; The bare-metal ARM compiler (the one I

work most of the time and on which I noticed the problem) comes directly from

/branches/ARM/embedded-4_7-branch and I have 2 versions of it (both fail). I

also have another ARM compiler that's probably from this branch too (but I'm

not sure), and it fails there too. A compiler from previous branch -

/branches/ARM/embedded-4_6-branch - also fails. As for the g++ on Linux, I

have no idea whether this is vanilla or modified for Arch package - any way I

can check that (other than comparing source code (; )? I definetely reports

just as 4.7.2... When I look at the source code for varasm.c in the 4.7

branch all I can tell is that at least the line of the report I'm seeing

matches the line in the code;



---



  /* Advance to offset of this element.

 Note no alignment needed in an array, since that is guaranteed

 if each element has the proper size.  */

  if ((local-field != NULL_TREE || local-index != NULL_TREE)

   fieldpos != local-total_bytes)

{

  gcc_assert (fieldpos = local-total_bytes); // this is line 4821 which

reports ICE

  assemble_zeros (fieldpos - local-total_bytes);

  local-total_bytes = fieldpos;

}



---



Is there anywhere I could download a really stock package of GCC in binary

form to check it (I'm not an expert, just a user, so compiling that myself is

rather hard...) - for Linux or Windows?

[Bug rtl-optimization/55757] New: Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757



 Bug #: 55757

   Summary: Suboptimal interrupt prologue/epilogue for ARMv7-M

(Cortex-M3)

Classification: Unclassified

   Product: gcc

   Version: 4.6.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: freddie_cho...@op.pl





With a Cortex-M3 microcontroller (ARMv7-M) and an empty interrupt handler

function:



void DMA_IRQHandler(void) __attribute((interrupt));

void DMA_IRQHandler(void)

{



}



Results in suboptimal prologue/epilogue:



23b4 DMA_IRQHandler:

void DMA_IRQHandler(void) __attribute((interrupt));

void DMA_IRQHandler(void)

{

23b4:4668  movr0, sp

23b6:f020 0107 bic.wr1, r0, #7

23ba:468d  movsp, r1

23bc:b501  push{r0, lr}

}

23be:e8bd 4001 ldmia.wsp!, {r0, lr}

23c2:4685  movsp, r0

23c4:4770  bxlr

...



Without the __attribute__ the function is fine, just a single bx lr.



This behavior is incorrect not only because r0 and lr are unused, but also

because on ARMv7-M these registers (r0-r3, lr, ip, sp, pc, psr) are saved by

hardware, so there's no point in saving them again.

[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757



--- Comment #1 from Freddie Chopin freddie_chopin at op dot pl 2012-12-20 
15:23:25 UTC ---

BTW - it seems that optimization settings don't make any difference here - the

code below was compiled with -Os, on all other levels (1,2,3) the assembly

looks like this:



2e90 DMA_IRQHandler:

void DMA_IRQHandler(void) __attribute((interrupt));

void DMA_IRQHandler(void)

{

2e90:4668  movr0, sp

2e92:f020 0107 bic.wr1, r0, #7

2e96:468d  movsp, r1

2e98:b401  push{r0}

}

2e9a:bc01  pop{r0}

2e9c:4685  movsp, r0

2e9e:4770  bxlr





So it just saves r0 only, without saving lr. It's actually 2 bytes smaller than

the assembly done for size optimizations (;



Without optimization (-O0) I get:



473c DMA_IRQHandler:

void DMA_IRQHandler(void) __attribute((interrupt));

void DMA_IRQHandler(void)

{

473c:4668  movr0, sp

473e:f020 0107 bic.wr1, r0, #7

4742:468d  movsp, r1

4744:b481  push{r0, r7}

4746:af00  addr7, sp, #0

}

4748:46bd  movsp, r7

474a:bc81  pop{r0, r7}

474c:4685  movsp, r0

474e:4770  bxlr



The commandline options used to compile:



arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections

-fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu99 -g -ggdb3

-fverbose-asm -Wa,-ahlms=out/uart.lst   -MD -MP -MF out/uart.d some include

dirs input file output file

[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757



--- Comment #3 from Freddie Chopin freddie_chopin at op dot pl 2012-12-20 
17:07:47 UTC ---

Indeed that's a trivial case, but other - useful - cases also show strange

behavior which I cannot clearly explain, so while we're at it I'd be grateful

for some explanation...



An interrupt handler function (void something(void)), but without attribute,

doing something inside (posts a FreeRTOS semaphore, calls vPortYieldFromISR()

if it's needed) actually saves a lot of registers on entry:

23b4:b507  push{r0, r1, r2, lr}

From what I know r0-r3 as scratch registers don't need to be saved on entry, as

it's the callers duty. There are also no parameters to be saved, as it's a void

function...



I observed the same behavior with some non-trivial functions from the lwIP

TCP/IP stack - they are also save scratch registers on entry, even when they

are void ...(void):



5d00 dns_init:

void

dns_init()

{

5d00:b537  push{r0, r1, r2, r4, r5, lr}



Is that a bug or maybe I don't understand the calling conventions? ;



BTW:

 The reason two registers are pushed, rather than one is that this is also 
 needed to

 keep the stack aligned and pushing two registers uses less code than 
 adjusting the stack in a separate insn.



But for optimization level 1, 2 and 3 only one reg is pushed...



Thx in advance!

[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)

[freddie_chopin at op dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757



--- Comment #6 from Freddie Chopin freddie_chopin at op dot pl 2012-12-21 
07:08:59 UTC ---

(In reply to comment #4)

 Former is better on code size, latter wins on performance. Hopefully this

 explains everything.



Indeed, it's clear now. Thank you for your time!