[Bug c++/95440] New: [coroutines] ICE with static members in promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440
Bug ID: 95440
Summary: [coroutines] ICE with static members in promise_type
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
Target Milestone: ---
https://gcc.godbolt.org/z/PoAYhX
#include
struct task
{
struct promise_type
{
auto get_return_object() const { return task{}; }
static constexpr std::suspend_never initial_suspend() { return
{}; }
/*static*/ constexpr std::suspend_never final_suspend() {
return {}; }
/*static*/ constexpr void return_void() {}
/*static*/ constexpr void unhandled_exception() {}
};
};
task
test_task()
{
co_await std::suspend_always{};
}
auto t = test_task();
int main() {}
[Bug c++/56222] Pointer to member in lambda should not require this to be captured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222 Michael Bruck changed: What|Removed |Added CC||bruck.michael at googlemail ||dot com --- Comment #7 from Michael Bruck 2013-03-17 21:12:24 UTC --- This issue applies to 4.7.x too. Any chance to get this backported?
[Bug libgcc/57256] New: Building for arm-elf with CFLAGS_FOR_TARGET=-mabi=aapcs-linux fails in libgcc/crtstuff.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57256 Bug ID: 57256 Summary: Building for arm-elf with CFLAGS_FOR_TARGET=-mabi=aapcs-linux fails in libgcc/crtstuff.c Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: bruck.michael at googlemail dot com Created attachment 30100 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30100&action=edit Diff of preprocessed crtstuff.c with and without -mabi=aapcs-linux This is not a new issue but I never needed crtstuff before and just used make -k CFLAGS_FOR_TARGET=-mcpu=arm1176jzf-s -marm -mabi=aapcs-linux -mfpu=vfp -mfloat-abi=softfp -mno-thumb-interwork -mno-long-calls -mtune=arm1176jzf-s -mlittle-endian ../../src/gcc-4.7.3/configure --target=arm-elf --enable-obsolete --with-newlib --enable-languages=c,c++ --disable-multilib --disable-nls --disable-shared --with-mode=arm --with-cpu=arm1176jzf-s --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=softfp --with-endian=little make ... ../../../../src/gcc-4.7.3/libgcc/crtstuff.c: In function '__do_global_dtors_aux': ../../../../src/gcc-4.7.3/libgcc/crtstuff.c:380:26: error: '__DTOR_LIST__' undeclared (first use in this function) ../../../../src/gcc-4.7.3/libgcc/crtstuff.c:380:26: note: each undeclared identifier is reported only once for each function it appears in The diff between the pre-processed files (1st file: with -mabi=aapcs-linux, doesn't comile; 2nd file: without -mabi=aapcs-linux, compiles) is attached as crtstuff.I.diff.
[Bug lto/51205] -flto discards memset/memcpy when only referenced by g++ generated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51205 Michael Bruck changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Michael Bruck 2012-06-19 02:13:02 UTC --- (In reply to comment #1) > Can you try if this is fixed with GCC 4.7.x when using binutils 2.22 or newer > and using the linker plugin? I tried with arm-eabi-gcc 4.7.1 and binutils 2.22.52 with the same command line and the bug is fixed in those. (don't know if it makes a difference that I switched to arm-eabi, but arm-elf won't build anymore for me)
[Bug c++/59571] New: [C++11] ICE when casting inside static member constexpr brace initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571
Bug ID: 59571
Summary: [C++11] ICE when casting inside static member
constexpr brace initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
$ cat ice.cpp
template
struct foo
{
static constexpr int bar{(int)-1};
};
$ g++ -std=c++11 -c ice.cpp
ice.cpp:4:37: internal compiler error: unexpected expression ‘(int)((-1))’ of
kind cast_expr
static constexpr int bar{(int)-1};
^
ice.cpp:4:37: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
...
$ g++ --version
g++ (GCC) 4.8.2
...
[Bug c/59661] New: documentation: __builtin_FUNCTION / _FILE listed as returning int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661 Bug ID: 59661 Summary: documentation: __builtin_FUNCTION / _FILE listed as returning int Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruck.michael at googlemail dot com http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html lists: — Built-in Function: int __builtin_FUNCTION () ... — Built-in Function: int __builtin_FILE () ... These should return some sort of string (ideally constexpr?).
[Bug c++/51205] New: -flto discards memset/memcpy when only referenced by g++ generated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51205
Bug #: 51205
Summary: -flto discards memset/memcpy when only referenced by
g++ generated code
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bruck.mich...@googlemail.com
When LTO encounters a call to memset (or memcpy) that was auto-generated by g++
it does not register that dependency and incorrectly throws away instances of
memset/memcpy if they are not referenced elsewhere by the program.
*** command line:
arm-elf-gcc -nostartfiles -static -nostdlib -nodefaultlibs -flto
-fwhole-program test.cpp -o test
*** error:
`memset' referenced in section `.text' of /tmp/cc7Mshjq.ltrans0.ltrans.o:
defined in discarded section `.text' of /tmp/ccBgVaJK.o (symbol from plugin)
collect2: ld returned 1 exit status
*** test.cpp:
typedef void (*action_t)(const unsigned char *);
extern "C" void _start(action_t action)
{
// this creates a call to memset() in g++
const unsigned char foo[256] = {};
action(foo);
}
#include
// uncomment for workaround:
// extern "C" void * memset(void * dst, int c, size_t length)
// __attribute__((externally_visible));
extern "C" void * memset(void * dst, int c, size_t length)
{
unsigned char * _dst = (unsigned char *)dst;
while (length--)
*_dst = c;
}
[Bug c++/51311] New: bogus array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
Bug #: 51311
Summary: bogus array bounds warning
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bruck.mich...@googlemail.com
command line:
arm-elf-g++ -Wall -Werror -O3 -std=gnu++0x -c foo.cpp
error:
foo.cpp: In function 'void bar()':
foo.cpp:23:44: error: array subscript is above array bounds
[-Werror=array-bounds]
The error is triggered by case 0x02, which in reality is not encountered with
in_data.
foo.cpp:
#include
char in_data[] = {0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00};
void bar()
{
size_t in_length = sizeof(in_data) / sizeof(in_data[0]);
size_t pos = 0;
while (pos < in_length)
{
size_t next = pos;
auto fill = [&](size_t data_len) -> bool
{
next = pos + 1 + data_len;
if (next > in_length)
return false;
memset(in_data + pos + 1, 0, data_len);
return true;
};
switch (in_data[pos])
{
case 0x01:
if (!fill(4))
return;
break;
case 0x02:
if (!fill(16))
return;
break;
}
pos = next;
}
}
[Bug c++/51311] bogus array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
--- Comment #2 from Michael Bruck
2011-11-28 02:34:16 UTC ---
(In reply to comment #1)
> I don't think this is a bug as in_data can be changed by a different function
> other than bar().
Before I stripped this down to a test case in_data was actually a const coming
from a second function (into which bar was being inlined by gcc).
Apart from that even if modified elsewhere gcc should IMO not assume that that
modification produces an ill-formed in_data that triggers case 0x02.
This revised version with static const behaves the same way:
#include
static const char in_data[] = {0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
0x00, 0x00};
void bar(char * dummy)
{
size_t in_length = sizeof(in_data) / sizeof(in_data[0]);
size_t pos = 0;
while (pos < in_length)
{
size_t next = pos;
auto copy = [&](size_t data_len) -> bool
{
next = pos + 1 + data_len;
if (next > in_length)
return false;
memcpy(dummy, in_data + pos + 1, data_len);
return true;
};
switch (in_data[pos])
{
case 0x01:
if (!copy(4))
return;
break;
case 0x02:
if (!copy(16))
return;
break;
}
pos = next;
}
}
[Bug c++/51311] bogus array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311 --- Comment #3 from Michael Bruck 2011-11-28 02:44:16 UTC --- (In reply to comment #2) > (In reply to comment #1) > > I don't think this is a bug as in_data can be changed by a different > > function > > other than bar(). > > Before I stripped this down to a test case in_data was actually a const coming > from a second function (into which bar was being inlined by gcc). > > Apart from that even if modified elsewhere gcc should IMO not assume that that > modification produces an ill-formed in_data that triggers case 0x02. > To illustrate a bit further why it is a problem, what I originally did was have bar() parse in_data. But not as global constant but passed as parameter. bar() in this case parses all sorts of different versions of in_data, some actually containing 0x02 and a valid length. To test this I added a second function to call bar() with a test case. That test case does not include 0x02. This triggers the error even though it is well-formed. I have to make the test case larger than 16+1 bytes to kill the error. But my test case and that function are otherwise correct code. Also curiously, if I add const before the "size_t in_length = ..." the error goes away.
[Bug c++/56126] New: -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
Bug #: 56126
Summary: -fno-exceptions produces constructors that rely on
exceptions to signal errors in operator new
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bruck.mich...@googlemail.com
Code generated with -fno-exceptions active does not check for nullptr on return
from operator new unless throw() is specified.
In code compiled with -fno-exceptions nothing can be thrown, consequently all
new operators should imply throw() or a warning/error should occur when new
operators without throw() are used.
$ cat test.cpp
#include
void * operator new(size_t size) //throw()
{
return 0;
}
struct foo
{
virtual void dummy() {}
};
int main()
{
foo * f = new foo();
printf("f = %p\n", f);
}
$ gcc test.cpp -fno-exceptions -fno-rtti
test.cpp: In function ‘void* operator new(size_t)’:
test.cpp:5:12: warning: ‘operator new’ must not return NULL unless it is
declared ‘throw()’ (or -fcheck-new is in effect)
$ ./a.out
Segmentation fault (core dumped)
The compiler diagnostic only appears because this example is reduced and the
compiler can evaluate the return value at compile time. In real-life the
compiler will generate code that assumes that all new errors return as
exceptions even though exceptions are disabled.
The example crashes when the vtable pointer is written, likewise but not shown
here the compiler calls the constructor with this == nullptr.
[Bug c++/56126] -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #2 from Michael Bruck 2013-01-28 05:12:57 UTC --- (In reply to comment #1) > The warning says you could use -fcheck-new . Yes, but in normal code you never see the warning.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #3 from Michael Bruck 2013-01-28 05:25:43 UTC --- (In reply to comment #1) > The warning says you could use -fcheck-new . Changed the title to account for this.
[Bug tree-optimization/42046] missed optimization (a?b|1:b&~1) where b is a load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046 Michael Bruck changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Bruck --- 5.2.1 with -Ofast produces ldr r2, .L5 ldr r3, [r2] cmp r0, #0 orrne r3, r3, #1 biceq r3, r3, #1 str r3, [r2] bx lr I'll mark it as fixed. There might be some trick to reduce the core logic (cmp/orrne/biceq) further, but that wasn't my issue.
[Bug c++/70755] New: [ARM] excessive struct alignment for globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
Bug ID: 70755
Summary: [ARM] excessive struct alignment for globals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
Target Milestone: ---
Discussion at the end
$ arm-none-eabi-g++.exe -std=c++11 -Ofast -c align_foo.cpp -S -fdata-sections
$ cat align_foo.cpp
struct S
{
bool val;
};
S s1; // 32 bit align
alignas(S) S s2;// 8 bit align
struct alignas(bool) SA
{
bool val;
};
struct alignas(long long) SB
{
bool val;
};
SA sa; // 32 bit align
SB sb; // 64 bit align
$ cat align_foo.s
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 23, 1
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.arm
.syntax divided
.file "align_foo.cpp"
.global sb
.global sa
.global s2
.global s1
.section.bss.s1,"aw",%nobits
.align 2
.type s1, %object
.size s1, 1
s1:
.space 1
.section.bss.s2,"aw",%nobits
.type s2, %object
.size s2, 1
s2:
.space 1
.section.bss.sa,"aw",%nobits
.align 2
.type sa, %object
.size sa, 1
sa:
.space 1
.section.bss.sb,"aw",%nobits
.align 3
.type sb, %object
.size sb, 8
sb:
.space 8
.ident "GCC: (GNU Tools for ARM Embedded Processors) 5.3.1 20160307
(release) [ARM/embedded-5-branch revision 234589]"
---
The code comments show how the respective variable was aligned in the assembly
output.
a) s1 should be byte aligned.
b) alignas works around the problem but only for s2 but not SA. Even though the
compiler clearly accepts the alignment increase for SB.
c) sb blocks 8 bytes, rather then just being 8 byte aligned
"-fdata-sections" is for clarity, without it we get basically the same,
although for sa the alignment could be unintentional:
...
.bss
.align 3
.type sb, %object
.size sb, 8
sb:
.space 8
.type sa, %object
.size sa, 1
sa:
.space 1
.type s2, %object
.size s2, 1
s2:
.space 1
.space 2
.type s1, %object
.size s1, 1
s1:
.space 1
[Bug c++/70755] [ARM] excessive struct alignment for globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
--- Comment #2 from Michael Bruck ---
(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice. By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
>
> Consider, for example, the object
>
> struct x
> {
> char a;
> char b;
> char c;
> char d;
> };
>
> struct x A, B;
>
> f()
> {
> B = A;
> }
>
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
>
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.
"for most users"
Maybe I should have specified -mcortex-m0 on the command line to illustrate the
point. For most Cortex-M0 users with 16 kB this 300% memory waste is a bad
trade-off.
Can you implement a command line option to deactivate this behavior?
Your reply did not address b) and c), should I open a separate bug to discuss
these?
[Bug c++/70755] [ARM] excessive struct alignment for globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
--- Comment #3 from Michael Bruck ---
(In reply to Michael Bruck from comment #2)
> (In reply to Richard Earnshaw from comment #1)
> > This is a deliberate design choice. By doing this we gain significant
> > benefits from having aligned objects, which helps with data copying and
> > other optimizations.
> >
> > Consider, for example, the object
> >
> > struct x
> > {
> > char a;
> > char b;
> > char c;
> > char d;
> > };
> >
> > struct x A, B;
> >
> > f()
> > {
> > B = A;
> > }
> >
> > Since the objects are aligned then this function can be optimized to single
> > 32-bit load and store operations that work very efficiently.
> >
> > As you've noticed, it is possible to force the alignment down to the
> > architectural minimums by annotations, but for most users it makes little
> > difference and the defaults are preferable.
>
> "for most users"
>
> Maybe I should have specified -mcortex-m0 on the command line to illustrate
> the point. For most Cortex-M0 users with 16 kB this 300% memory waste is a
> bad trade-off.
>
> Can you implement a command line option to deactivate this behavior?
>
> Your reply did not address b) and c), should I open a separate bug to
> discuss these?
A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice. By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
>
> Consider, for example, the object
>
> struct x
> {
> char a;
> char b;
> char c;
> char d;
> };
>
> struct x A, B;
>
> f()
> {
> B = A;
> }
>
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
>
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.
A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.
[Bug c++/70938] New: internal compiler error: in tsubst_copy, at cp/pt.c:13008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70938
Bug ID: 70938
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:13008
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
Target Milestone: ---
$ cat ice-20160504.cpp
struct bar_t
{
int i;
};
template
struct foo_t
{
bar_t & bar = *(bar_t *)0x7770;
int & i = bar.i;
};
constexpr auto foo = foo_t{};
$ arm-none-eabi-g++.exe -std=c++14 ice-20160504.cpp
ice-20160504.cpp:13:33: internal compiler error: in tsubst_copy, at
cp/pt.c:13008
constexpr auto foo = foo_t{};
^
...
$ arm-none-eabi-g++.exe -V
...
gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]
(GNU Tools for ARM Embedded Processors)
[Bug c++/77771] New: internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Bug ID: 1
Summary: internal compiler error: in cxx_eval_bit_field_ref, at
cp/constexpr.c:2090
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
Target Milestone: ---
struct S
{
charx[2];
unsignedy;
};
constexpr bool func(const S s)
{
return s.x[0] != 42 || s.x[1] != 0;
}
static_assert(!func({{42, 7}, 0}), "bla");
---
Compiled with -std=c++11 -O on various compilers (http://gcc.godbolt.org/)
starting with 4.7.1 up to 7 I get an ICE:
Example with 5.4:
12 : in constexpr expansion of 'func(S{char [2]{'*', '\007'}, 0u})'
12 : internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
static_assert(!func({{42, 7}, 0}), "bla");
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612 --- Comment #6 from Michael Bruck --- (In reply to Manuel López-Ibáñez from comment #4) > > What do you think? > Looks great. My main beef was that the two errors were merged into one diagnostic.
[Bug c++/51311] bogus array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311 Michael Bruck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Bruck --- Not reproducible with 4.8.2.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #5 from Michael Bruck --- @Olaf "5.3.4 New 13 [Note: unless an allocation function is declared with a non-throwing exception-specification (15.4), it indicates failure to allocate storage by throwing a std::bad_alloc exception (Clause 15, 18.6.2.1); it returns a non-null pointer otherwise. If the allocation function is declared with a non-throwing exception-specification, it returns null to indicate failure to allocate storage and a non-null pointer otherwise. —end note] If the allocation function returns null, initialization shall not be done, the deallocation function shall not be called, and the value of the new-expression shall be null."
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #9 from Michael Bruck --- > Jonathan: Using -fno-exceptions says "I do not want ISO C++" so quoting the > standard isn't very relevant. > Olaf: No, as you could (should?) abort/terminate instead of returning NULL. I quoted it to illustrate that returning NULL is the intuitive option here, while abort() is a completely new approach. Returning NULL is what I would expect to be the case when -fno-exceptions is active and it is what happens in the libc++ implementation AFAIK. > Why would you want an operator new that can't throw but is declared to > potentially throw? Because -fno-exceptions suggests to the user that they can produce safe code without using any exception-specific C++ syntax. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html "The last language feature needing to be transformed by -fno-exceptions is treatment of exception specifications on member functions. Fortunately, the compiler deals with this by ignoring exception specifications and so no alternate source markup is needed." If the authors of the libstdc++ docs get this wrong, how is the average compiler user expected to know this? Likewise GCC's documentation also pretends this case doesn't exist: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/C_002b_002b-Dialect-Options.html "-fcheck-new Check that the pointer returned by operator new is non-null before attempting to modify the storage allocated. This check is normally unnecessary because the C++ standard specifies that operator new only returns 0 if it is declared ‘throw()’, in which case the compiler always checks the return value even without this option. In all other cases, when operator new has a non-empty exception specification, memory exhaustion is signalled by throwing std::bad_alloc. See also ‘new (nothrow)’. " > The exception specification is defined by the language to inform the compiler > whether to check the result or not, so use that. > If declaring it like that really isn't possible, then you should use > -fcheck-new, but it seems OK to not enable that automatically and rely on > correct exception specifications. As you pointed out we are outside the standard with -fno-exceptions. There is certainly no rule that prevents the compiler from issuing a warning when it generates code that is highly unlikely to be safe.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #11 from Michael Bruck --- (In reply to Olaf van der Spek from comment #10) > > I quoted it to illustrate that returning NULL is the intuitive option here, > > while abort() is a completely new approach. Returning NULL is what I would > > expect to be the case when -fno-exceptions is active and it is what happens > > in > > the libc++ implementation AFAIK. > > -fno-exceptions transforms throws into aborts in the STL. > Unfortunately it doesn't do that for other code but I've filed a > feature request for to fix that. > > Given this transformation aborting would be the natural consequence. > What does the GCC STL do? throwing is undefined behavior with -fno-exceptions. Allocation failure is a simple error and should not kill your program. > BTW, what's your use case? Do you really want to check NULL on every > call to new? With -fno-exceptions you have to check all functions for errors, including allocation.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #14 from Michael Bruck --- (In reply to Olaf van der Spek from comment #12) > > Allocation failure is a > > simple error and should not kill your program. > > It's far from simple to handle properly and to do better then abort. In systems that use different types of allocators for different purposes it can be a fairly common case. > >> BTW, what's your use case? Do you really want to check NULL on every > >> call to new? > > > > With -fno-exceptions you have to check all functions for errors, including > > allocation. > > What's your use case? Memory constrained systems
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #15 from Michael Bruck --- (In reply to Jonathan Wakely from comment #13) > (In reply to Michael Bruck from comment #11) > > throwing is undefined behavior with -fno-exceptions. > > No it isn't, it's ill-formed due to a syntax error. That's very different to > undefined behaviour. I misunderstood Olaf, I guess he means they replace them via preprocessor macros. In any case it is different from an allocation failure, which was my point.
[Bug target/64774] New: [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774
Bug ID: 64774
Summary: [ARM/thumb] missed optimization: pc relative ldr used
when constant can be derived from register
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
In the example the second write address of each function can either be
generated using 'str' with an immediate offset or using an adds with an
immediate addend.
The compiler does this for test1-3. For test4-6 it emits a pc-relative ldr
instruction and a 32bit constant. This increases size and likely impacts
execution speed.
cat test.c
void test1()
{
*(unsigned *)4 = 0x666;
*(unsigned *)(4 + 4) = 0x666;
}
void test2()
{
*(unsigned *)4 = 0x666;
*(unsigned *)(4 + 128) = 0x666;
}
void test3()
{
*(unsigned *)0x444 = 0x666;
*(unsigned *)(0x444 + 4) = 0x666;
}
void test4()
{
*(unsigned *)0x444 = 0x666;
*(unsigned *)(0x444 + 128) = 0x666;
}
void test5()
{
*(unsigned *)0x = 0x666;
*(unsigned *)(0x + 4) = 0x666;
}
void test6()
{
*(unsigned *)0x = 0x666;
*(unsigned *)(0x + 128) = 0x666;
}
arm-none-eabi-gcc -c test.c -mthumb -mcpu=cortex-m0 -mtune=cortex-m0 -Ofast -o
test.o
:
0:2204 movsr2, #4
2:4b02 ldrr3, [pc, #8]; (c )
4:6013 strr3, [r2, #0]
6:6053 strr3, [r2, #4]
8:4770 bxlr
a:46c0 nop; (mov r8, r8)
c:0666 .word0x0666
0010 :
10:2204 movsr2, #4
12:4b02 ldrr3, [pc, #8]; (1c )
14:6013 strr3, [r2, #0]
16:3280 addsr2, #128; 0x80
18:6013 strr3, [r2, #0]
1a:4770 bxlr
1c:0666 .word0x0666
0020 :
20:4b02 ldrr3, [pc, #8]; (2c )
22:4a03 ldrr2, [pc, #12]; (30 )
24:6013 strr3, [r2, #0]
26:6053 strr3, [r2, #4]
28:4770 bxlr
2a:46c0 nop; (mov r8, r8)
2c:0666 .word0x0666
30:0444 .word0x0444
0034 :
34:4b02 ldrr3, [pc, #8]; (40 )
36:4a03 ldrr2, [pc, #12]; (44 )
38:6013 strr3, [r2, #0]
3a:4a03 ldrr2, [pc, #12]; (48 )
3c:6013 strr3, [r2, #0]
3e:4770 bxlr
40:0666 .word0x0666
44:0444 .word0x0444
48:04c4 .word0x04c4
004c :
4c:4b02 ldrr3, [pc, #8]; (58 )
4e:4a03 ldrr2, [pc, #12]; (5c )
50:6013 strr3, [r2, #0]
52:4a03 ldrr2, [pc, #12]; (60 )
54:6013 strr3, [r2, #0]
56:4770 bxlr
58:0666 .word0x0666
5c: .word0x
60:4448 .word0x4448
0064 :
64:4b02 ldrr3, [pc, #8]; (70 )
66:4a03 ldrr2, [pc, #12]; (74 )
68:6013 strr3, [r2, #0]
6a:4a03 ldrr2, [pc, #12]; (78 )
6c:6013 strr3, [r2, #0]
6e:4770 bxlr
70:0666 .word0x0666
74: .word0x
78:44c4 .word0x44c4
Compiled using:
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2014-q4-major/+download/gcc-arm-none-eabi-4_9-2014q4-20141203-win32.exe
[Bug target/64774] [ARM/thumb] missed optimization: pc relative ldr used when constant can be derived from register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774 --- Comment #2 from Michael Bruck --- (In reply to Richard Earnshaw from comment #1) > Although the compiler tries to find some common cases, it is generally > infeasible to detect all the possible permutations that exist. Furthermore, > in real code generating common expressions in this way can increase register > pressure and have additional impact on some optimization passes. > > I don't hold out much hope of this sort of problem ever being entirely fixed. I wonder if the logic that recognizes cases 1-3 could be expanded to work with the rest too. It almost looks to me as if there is a bug that checks the size of the constant and not the difference to decide what can be substituted with an addition. The register pressure issue could be avoided if the optimization is applied later and only for cases where the value already happens to be in a register.
[Bug c++/77277] New: -fdiagnostics-color=always disabled on _WIN32 for no discernible reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77277 Bug ID: 77277 Summary: -fdiagnostics-color=always disabled on _WIN32 for no discernible reason Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bruck.michael at googlemail dot com Target Milestone: --- diagnostic-color.c completely disables colorization for the _WIN32 platform. However both the most recent Windows 10 cmd.exe terminal as well as existing terminal emulators available on older Windows versions fully support the Escape sequences generated by gcc. Proposal: -fdiagnostics-color=always should always emit color codes If isatty() is not reliable or unavailable on _WIN32 then should_colorize() could be short-circuited to return false on _WIN32.
