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
: 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
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
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 *)0x
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
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
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046
Michael Bruck changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774
--- Comment #2 from Michael Bruck bruck.michael at googlemail dot com ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #14 from Michael Bruck bruck.michael at googlemail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #15 from Michael Bruck bruck.michael at googlemail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #11 from Michael Bruck bruck.michael at googlemail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #9 from Michael Bruck bruck.michael at googlemail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #5 from Michael Bruck bruck.michael at googlemail dot com ---
@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
--- Comment #6 from Michael Bruck bruck.michael at googlemail dot com ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
Michael Bruck bruck.michael at googlemail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
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
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
$ cat ice.cpp
template class
struct foo
{
static constexpr int bar{(int)-1};
};
$ g++ -std=c++11 -c ice.cpp
ice.cpp:4:37: internal compiler
: 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=30100action=edit
Diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222
Michael Bruck bruck.michael at googlemail dot com changed:
What|Removed |Added
CC
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #2 from Michael Bruck bruck.michael at googlemail dot com
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #3 from Michael Bruck bruck.michael at googlemail dot com
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51205
Michael Bruck bruck.michael at googlemail dot com changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
--- Comment #2 from Michael Bruck bruck.michael at googlemail dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
--- Comment #3 from Michael Bruck bruck.michael at googlemail dot com
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
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
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:
29 matches
Mail list logo
