https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58798
--- Comment #11 from Olaf van der Spek ---
(In reply to Eric Gallager from comment #10)
> Updating the title accordingly.
The title doesn't reflect the original issue anymore, should a new issue be
filed for that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58798
Olaf van der Spek changed:
What|Removed |Added
CC||olafvdspek at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #12 from Olaf van der Spek ---
On Thu, Jan 8, 2015 at 10:20 PM, bruck.michael at googlemail dot com
wrote:
> throwing is undefined behavior with -fno-exceptions.
Says who?
> Allocation failure is a
> simple error and should not kil
: unassigned at gcc dot gnu.org
Reporter: olafvdspek at gmail dot com
Lots of programs abort / terminate when new fails to allocate memory. Would it
be possible to have an option to make new noexcept, possibly allowing more
optimizations as noexcept will have a ripple effect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #10 from Olaf van der Spek ---
On Tue, Jan 6, 2015 at 2:22 PM, bruck.michael at googlemail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
>
> --- Comment #9 from Michael Bruck ---
>> Jonathan: Using -fno-excepti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #8 from Olaf van der Spek ---
(In reply to Michael Bruck from comment #0)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64482
Olaf van der Spek changed:
What|Removed |Added
Severity|normal |enhancement
++
Assignee: unassigned at gcc dot gnu.org
Reporter: olafvdspek at gmail dot com
Currently -fno-exceptions is partially implemented in the std library. throw is
replaced by abort(), try and catch are basically no-ops. However, user code
doesn't benefit from this.
Could these things be implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
Olaf van der Spek changed:
What|Removed |Added
CC||olafvdspek at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639
--- Comment #11 from Olaf van der Spek ---
Perhaps, but that's not the ideal route.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639
--- Comment #9 from Olaf van der Spek ---
Standards bodies prefer to standardize existing practise, so I think that's the
wrong way to go. Ideally it's first implemented and only then it gets
standardized.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639
--- Comment #7 from Olaf van der Spek ---
(In reply to Andrew Pinski from comment #6)
> Your own library.
Reinventing the wheel time and time again leads to code duplication which is
bad.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALI
: unassigned at gcc dot gnu.org
Reporter: olafvdspek at gmail dot com
assert() is nice, but sometimes the expression should be evaluated (but not
checked) even when NDEBUG is defined, could we have (gnu) verify() for this?
Sometimes you also want the expression to be checked under NDEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494
--- Comment #2 from Olaf van der Spek ---
(In reply to Andrew Pinski from comment #1)
> strtol is part of glibc and not part of GCC.
Ah, thx. OT: What is assert part of?
> You can code your own strtol2
> and not have to be part of a library re
: unassigned at gcc dot gnu.org
Reporter: olafvdspek at gmail dot com
strtol doesn't support non-null-terminated input, often requiring input to be
copied into a null-terminater string before it can be parsed.
It skips whitespace, which may not be desired.
It stops when a non-n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756
--- Comment #6 from Olaf van der Spek ---
Hi Jonathan,
The difference between < > and " " is implementation defined. AFAIK GCC only
searches the include path with < > and first searches relative to the current
file with " ". So the standard can't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857
Olaf van der Spek changed:
What|Removed |Added
Status|VERIFIED|UNCONFIRMED
Resolution|DUPLIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #2 from Olaf van
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579
--- Comment #4 from Olaf van der Spek 2011-06-29
19:59:57 UTC ---
Aren't 1 and 2 the same thing?
I'm not sure what 3 is, but it's about a Hello World example using AM and PCH.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576
--- Comment #8 from Olaf van der Spek 2011-06-29
19:01:53 UTC ---
/usr/include was just an example and not the main point of this feature
request.
I expect GCC devs to be smart enough to pick the best implementation of a
certain request themselve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576
--- Comment #6 from Olaf van der Spek 2011-06-29
18:31:52 UTC ---
> why should they be excluded because they're not under /usr/include?
Because unless you tell GCC, GCC won't know they're good candidates.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576
--- Comment #4 from Olaf van der Spek 2011-06-29
18:12:24 UTC ---
Suppose your app has 10557 include directives. What do you add to your PCH?
Why /usr/include? Because these headers are unlikely to change, so they're a
good candidate for PCH.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576
--- Comment #2 from Olaf van der Spek 2011-06-29
17:32:02 UTC ---
So why exactly can't this be done?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579
--- Comment #2 from Olaf van der Spek 2011-06-29
14:46:00 UTC ---
I kinda agree, but:
Automake (and CMake) devs say they don't know how to properly support PCHs. So
maybe GCC devs could help them and ensure end users can use this feature of
GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579
Summary: Document how to use PCH with Automake
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: pch
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576
Summary: Option to suggest headers for addition to PCH
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: pch
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857
Summary: Pragma once warning when compiling PCH
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
AssignedTo: unass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
--- Comment #11 from Olaf van der Spek 2011-02-21
13:11:04 UTC ---
> Dup.
No kidding?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
--- Comment #9 from Olaf van der Spek 2011-02-21
12:47:24 UTC ---
> > So "The list in the manual already." is false.
>
> The information is in the manual, even if not as an explicit list.
That's true, but not what was said.
> I expect adding a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
--- Comment #3 from Olaf van der Spek 2011-02-21
09:37:03 UTC ---
g++ -o b.h.gch a.h
g++ c.cpp
a.h:
#pragma once // a.h:1:9: warning: #pragma once in main file
c.cpp:
#include "b.h"
#include "b.h" // c.cpp:2:15: error: b.h: No such file or di
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
--- Comment #4 from Olaf van der Spek 2011-02-20
21:07:07 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > It would also be nice to list all warnings not included in -Wall -Wextra.
>
> The list in the manual already.
Where?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
--- Comment #1 from Olaf van der Spek 2011-02-20
15:33:21 UTC ---
It would also be nice to list all warnings not included in -Wall -Wextra.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824
Summary: Option to enable all warning (-Wall-real?)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47823
Summary: #pragma once not documented
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Olaf van der Spek changed:
What|Removed |Added
CC||olafvdspek at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756
--- Comment #2 from Olaf van der Spek 2011-02-15
16:24:06 UTC ---
Cases where < > would work but where " " is used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756
Summary: Warning for #include " " instead of < >
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: preprocessor
Assigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700
--- Comment #8 from Olaf van der Spek 2011-02-11
17:48:06 UTC ---
This isn't really about a dialect, so it still doesn't make sense.
And: Why isn't it included in -Wall -Wextra -pedantic?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700
--- Comment #5 from Olaf van der Spek 2011-02-11
17:18:05 UTC ---
I don't get why it's listed on that page. IMO it should be at
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
Why isn't it included in -Wall -Wextra -pedant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
--- Comment #5 from Olaf van der Spek 2011-02-11
17:06:57 UTC ---
Why not? It doesn't seem too complex to me. The compiler writes a comment to
the object file, the linker reads this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700
Olaf van der Spek changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700
Summary: Warning for C casts in C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47699
--- Comment #2 from Olaf van der Spek 2011-02-11
16:44:21 UTC ---
Nice! I actually read about that at
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html but didn't realize
-include was a command line option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
--- Comment #3 from Olaf van der Spek 2011-02-11
16:42:45 UTC ---
Somebody?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47699
Summary: Support PCH without #include
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: pch
AssignedTo: unassig...@gcc.g
--- Comment #2 from olafvdspek at gmail dot com 2010-06-07 03:01 ---
Would that be a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
ry: Support for automatic linking via pragma
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olafvdspek at gmail
--- Comment #3 from olafvdspek at gmail dot com 2008-03-03 16:30 ---
Hmm, should I change the status back to NEW manually?
--
olafvdspek at gmail dot com changed:
What|Removed |Added
--- Comment #2 from olafvdspek at gmail dot com 2008-02-02 15:33 ---
Created an attachment (id=15078)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15078&action=view)
Preprocessor output (I hope)
I hope -E is the right option.
--
http://gcc.gnu.org/bugzilla/show_bug
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olafvdspek at gmail dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35057
--- Comment #10 from olafvdspek at gmail dot com 2007-12-12 12:29 ---
> Just use
It'd be nice if the deprecated warning mentioned that file.
--
olafvdspek at gmail dot com changed:
What|Removed
--- Comment #4 from olafvdspek at gmail dot com 2007-12-09 18:56 ---
I reported the bug below to Debian. I'm not that familiar with those headers,
but I think it'd be a good idea to not deprecate them until the replacements
have been available for quite a while.
http://bugs.
--- Comment #3 from olafvdspek at gmail dot com 2007-12-09 18:52 ---
Hasn't the comment from [EMAIL PROTECTED] been implemented?
AFAIK works in 4.3 and generates the deprecation warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
59 matches
Mail list logo
