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 objects
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 optimi
++
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 ---
(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
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 immedi
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.
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 s
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
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 ill
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 (Claus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311
Michael Bruck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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.
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
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=30100&action=edit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222
Michael Bruck changed:
What|Removed |Added
CC||bruck.michael at googlemail
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.
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.
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=51205
Michael Bruck changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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
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 act
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
C
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: UNCONFI
29 matches
Mail list logo
