[Bug preprocessor/47756] Warning for #include instead of

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug preprocessor/47756] Warning for #include instead of

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com --- 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

[Bug preprocessor/47857] Pragma once warning when compiling PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|VERIFIED

[Bug libgcc/60494] New: A better strtol

: 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-number

[Bug libgcc/60494] A better strtol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com --- (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

[Bug c/60639] New: New Assert Variants

: 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

[Bug c/60639] New Assert Variants

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug c/60639] New Assert Variants

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug c/60639] New Assert Variants

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 --- Comment #7 from Olaf van der Spek olafvdspek at gmail dot com --- (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.

[Bug c/60639] New Assert Variants

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 --- Comment #9 from Olaf van der Spek olafvdspek at gmail dot com --- 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.

[Bug c/60639] New Assert Variants

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 --- Comment #11 from Olaf van der Spek olafvdspek at gmail dot com --- Perhaps, but that's not the ideal route.

[Bug c++/39437] New: Support for automatic linking via pragma

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 dot com http

[Bug libstdc++/33832] Can't tell gcc 4.3 libstdc++ API from gcc 4.2 libstdc++ API

--- Comment #3 from olafvdspek at gmail dot com 2007-12-09 18:52 --- Hasn't the comment from [EMAIL PROTECTED] been implemented? AFAIK ext/hash_set works in 4.3 and generates the deprecation warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832

[Bug libstdc++/33832] Can't tell gcc 4.3 libstdc++ API from gcc 4.2 libstdc++ API

--- 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.debian.org

[Bug libstdc++/33832] hash_set moved to backwards

--- Comment #10 from olafvdspek at gmail dot com 2007-12-12 12:29 --- Just use tr1/unordered_set It'd be nice if the deprecated warning mentioned that file. -- olafvdspek at gmail dot com changed: What|Removed |Added

[Bug c++/35057] New: Integer variable value lost due to optimizations?

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

[Bug c++/35057] Integer variable value lost due to optimizations?

--- 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=15078action=view) Preprocessor output (I hope) I hope -E is the right option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug c++/35057] Integer variable value lost due to optimizations?

--- 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

[Bug preprocessor/47857] Pragma once warning when compiling PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED

[Bug preprocessor/39029] #pragma once is not exported from the precompiled headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added CC||olafvdspek

[Bug preprocessor/47823] New: #pragma once not documented

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:

[Bug other/47824] New: Option to enable all warning (-Wall-real?)

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:

[Bug other/47824] Option to enable all warning (-Wall-real?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #1 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-20 15:33:21 UTC --- It would also be nice to list all warnings not included in -Wall -Wextra.

[Bug other/47824] Option to enable all warning (-Wall-real?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug preprocessor/39029] #pragma once is not exported from the precompiled headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029 --- Comment #3 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug other/47824] Option to enable all warning (-Wall-real?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug other/47824] Option to enable all warning (-Wall-real?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #9 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug other/47824] Option to enable all warning (-Wall-real?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47824 --- Comment #11 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 13:11:04 UTC --- Dup. No kidding?

[Bug preprocessor/47857] New: Pragma once warning when compiling PCH

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:

[Bug pch/49576] New: Option to suggest headers for addition to PCH

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

[Bug pch/49579] New: Document how to use PCH with Automake

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:

[Bug pch/49579] Document how to use PCH with Automake

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug pch/49576] Option to suggest headers for addition to PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com 2011-06-29 17:32:02 UTC --- So why exactly can't this be done?

[Bug pch/49576] Option to suggest headers for addition to PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576 --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug pch/49576] Option to suggest headers for addition to PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576 --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com 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.

[Bug pch/49576] Option to suggest headers for addition to PCH

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49576 --- Comment #8 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug pch/49579] Document how to use PCH with Automake

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579 --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com 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.

[Bug pch/47699] New: Support PCH without #include

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:

[Bug c++/39437] Support for automatic linking via pragma

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437 --- Comment #3 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-11 16:42:45 UTC --- Somebody?

[Bug pch/47699] Support PCH without #include

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47699 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com 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.

[Bug c++/47700] New: Warning for C casts in C++

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:

[Bug c++/47700] Warning for C casts in C++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug c++/39437] Support for automatic linking via pragma

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437 --- Comment #5 from Olaf van der Spek olafvdspek at gmail dot com 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.

[Bug c++/47700] Warning for C casts in C++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700 --- Comment #5 from Olaf van der Spek olafvdspek at gmail dot com 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

[Bug c++/47700] Warning for C casts in C++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700 --- Comment #8 from Olaf van der Spek olafvdspek at gmail dot com 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?

[Bug c++/47700] Warning for C casts in C++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47700 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug c++/39437] Support for automatic linking via pragma

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug preprocessor/47756] New: Warning for #include instead of

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 AssignedTo:

[Bug preprocessor/47756] Warning for #include instead of

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-15 16:24:06 UTC --- Cases where would work but where is used.

[Bug c++/39437] Support for automatic linking via pragma

--- 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

[Bug c++/64482] New: No Exceptions Improvements

++ 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 implemented

[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 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added CC

[Bug c++/64482] No Exceptions Improvements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64482 Olaf van der Spek olafvdspek at gmail dot com changed: What|Removed |Added Severity|normal

[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 #10 from Olaf van der Spek olafvdspek at gmail dot com --- On Tue, Jan 6, 2015 at 2:22 PM, bruck.michael at googlemail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #9 from

[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 #8 from Olaf van der Spek olafvdspek at gmail dot com --- (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

[Bug c++/64529] New: Noexcept New

: 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?

[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 #12 from Olaf van der Spek olafvdspek at gmail dot com --- On Thu, Jan 8, 2015 at 10:20 PM, bruck.michael at googlemail dot com gcc-bugzi...@gcc.gnu.org wrote: throwing is undefined behavior with -fno-exceptions. Says who

[Bug c++/58798] class with a class reference member generates unjustified warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58798 Olaf van der Spek changed: What|Removed |Added CC||olafvdspek at gmail dot com

[Bug c++/58798] class with a class reference member generates a warning that ought to be disableable with -Wpacked

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?