[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?
[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 --- Comment #9 from Olaf van der Spek --- Any conclusions? Could classes with references be packed?
[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? 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. 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?
[Bug c++/64529] New: Noexcept New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64529 Bug ID: 64529 Summary: Noexcept New Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: 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 #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 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 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. -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? 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. I think we disagree on that part. BTW, what's your use case? Do you really want to check NULL on every call to new? Olaf
[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/error should occur when new operators without throw() are used. No, as you could (should?) abort/terminate instead of returning NULL.
[Bug c++/64482] New: No Exceptions Improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64482
Bug ID: 64482
Summary: No Exceptions Improvements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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 in the compiler instead?
Ideally a throw would still result in something like:
terminate called after throwing an instance of 'std::runtime_error'
what(): Bah
Aborted
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html
#include stdexcept
int main()
{
throw std::runtime_error(Bah);
}
[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||olafvdspek at gmail dot com --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com --- Isn't abort() called when new fails with -fno-exceptions?
[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 |enhancement
[Bug c/60639] New: New Assert Variants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60639 Bug ID: 60639 Summary: New Assert Variants Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: 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, could we have (gnu) assure for this?
[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|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com --- I could create my own header for assert() too, but it's still in the standard.
[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|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com --- (In reply to Andrew Pinski from comment #3) Well don't call it assert, call it my_assert or something like that. We should not be adding random extensions if they can be done other places. Then what is the criteria for including something in GCC (or libc)? And what'd be a better place? Also I think assert.h comes from libc and not GCC. glibc?
[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 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 to be part of a library really. Of course I can, but I'm not a fan of code duplication and writing a (correct) floating point number parser isn't trivial.
[Bug libgcc/60494] New: A better strtol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494 Bug ID: 60494 Summary: A better strtol Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcc Assignee: 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 character is read, which may not be desired. It returns 0 on error, which may not be desired eithers Sometimes one wants to distinguish between 0 and error. Could a better strtol (and variants) be provided? Something like int strtol2(long* out, const char* s, size_t n, char** endptr, int base); It should not skip whitespace. If endptr is NULL, it should return an error if garbage is read after the number.
[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 with . So the standard can't offer better guidance. Let's consider GCC on Linux. Do you use only for standard C / C++ headers or do you also use it for for example zlib and other platform provided headers? What do major coding styles say?
[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|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com --- Comment 2 contains a clear definition. If is used but you don't find the file after looking relative to the current file (but before looking in the include path) a warning should be issued.
[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|UNCONFIRMED Resolution|DUPLICATE | --- Comment #4 from Olaf van der Spek olafvdspek at gmail dot com 2012-04-28 14:39:51 UTC --- (In reply to comment #3) If you're going to change the status please check what VERIFIED means (we don't use that status in this bugzilla) Oops
[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 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com 2011-12-15 10:41:07 UTC --- (In reply to comment #1) Dup of bug 39029 which shows the warning is just part of the symptom. *** This bug has been marked as a duplicate of bug 39029 *** It's *not* a duplicate. This one is about generating the .gch. The other one is about using the .gch (and not about the warning message).
[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 AssignedTo: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com Determining which headers should be included in a PCH header is a manual process and it's easy to forget some headers. Would it be possible to add an option that when enabled, suggests headers that should be added? Potential headers are those that live in /usr/include and are not yet part of the 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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com PCH is a useful feature, but using it with automake isn't trivial. Could you document how to use it?
[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 can use this feature of GCC.
[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 a good candidate for PCH.
[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 of a certain request themselves.
[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 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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com g++ a.h a.h: #pragma once // warning: #pragma once in main file
[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: b.h: No such file or directory
int main()
{
}
[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|UNCONFIRMED Resolution|DUPLICATE | --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-21 09:45:21 UTC --- (In reply to comment #5) It is implicitly in the manual as those that are not mentioned as enabled by Wall or Wextra. So The list in the manual already. is false. It would be nice to have a list of options enabled by default and another list of options never enabled by default or by other option. However, I doubt that any of the current GCC devs will ever bother to create such lists, so if you are interested, please send a documentation patch. It is a matter of reading about all warning options mentioned in http://gcc.gnu.org/onlinedocs/gcc/ and creating the lists. I'll have a look. However, I still think an option to really enable (almost) all warnings should be added. I don't agree with the comments in the earlier report.
[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. I expect adding an explicit list would soon get out of date as it just increases the burden on contributors when adding new options. Adding options that can't be easily enabled / found doesn't seem very useful. The fact you don't agree doesn't change the fact this is a duplicate of that report, marking it as such helps keep the discussion in one place. Please don't reopen this report. How do I reopen the other report? If you want a new one for the documentation issue please open a new PR. Why? Seems easier to use this one for it.
[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/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 at gmail dot com --- Comment #1 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-20 15:15:08 UTC --- Could you attach a minimal testcase?
[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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com #pragma once appears to be undocumented http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Pragmas.html
[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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com Could an option be added that enables all warnings?
[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 already. Where?
[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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com A lot of times, #include is used while #include should be used. Could a (optional) warning for this be added?
[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++/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|UNCONFIRMED URL||http://gcc.gnu.org/onlinedo ||cs/gcc-4.5.2/gcc/C_002b_002 ||b-Dialect-Options.html#inde ||x-Wno_002dold_002dstyle_002 ||dcast-178 Resolution|WORKSFORME | --- Comment #10 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-12 13:24:46 UTC --- (In reply to comment #9) (In reply to comment #8) This isn't really about a dialect, so it still doesn't make sense. By dialect, the manual means language, as in warning specific to the C++ language. Does it? Why it uses the word dialect completely escapes to me? Because a lot of the options are about dialects. Things that allow more (or less) than standard C++. Feel free to propose in g...@gcc.gnu.org to change the word and see what people think. We've got this bug already, I'm not subscribed to that list. And: Why isn't it included in -Wall -Wextra -pedantic? Because old-style casts are still used everywhere, it is more of a matter of Even in C++? style, and adding new warnings to -Wall -Wextra will break building any project that uses -Werror for code that is surely working fine. Users complain about this all the time. Isn't that the consequence of using -Werror? I've got perfectly fine code too that generates warnings. (-pedantic is for GCC specific extensions, so it doesn't apply).
[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 Resolution|WONTFIX | --- Comment #7 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-12 15:08:32 UTC --- (In reply to comment #6) If it doesn't seem very complex, please go ahead and implement it: The concept is simple, the implementation may be simple but for someone not familiar with the source at all it's far from simple. I'll first ask people from the gold linker what they think about this idea and have any ideas for implementation.
[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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com PCH looks for all.h.gch when it encounters #include all.h. Projects that don't use PCH probably don't have a #include all.h at the top of every source file. Could an option be added like VC /Yu (/Yu all.h.gch) that would cause the compiler to use all.h.gch without an #include being present? This would make using PCH simpler and less intrusive.
[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: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com Some consider C casts in C++ code bad. g++ -Wall -pedantic doesn't warn. Could this (optional) warning be added?
[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|UNCONFIRMED Resolution|WORKSFORME | --- Comment #3 from Olaf van der Spek olafvdspek at gmail dot com 2011-02-11 17:05:20 UTC --- Can't find it at http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options Why isn't it included in -Wall -Wextra -pedantic?
[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 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 --- 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++/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++/39437] New: Support for automatic linking via pragma
MSVC supports the following pragma, which can be used to automatically link a library when a header file is included. This is used by for example Boost. #pragma comment(lib, requiredLibrary.lib) Unfortunately, g++ doesn't support this. Could you add it? -- Summary: 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 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
[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 Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35057
[Bug c++/35057] New: Integer variable value lost due to optimizations?
Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456930
With -O2 it calls bind with 0, without and with -O3 it works fine.
Asio is a C++ networking library.
$ g++ -I misc -lpthread t.cpp strace ./a.out
...
bind(6, {sa_family=AF_INET, sin_port=htons(2711),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
...
$ g++ -I misc -O2 -lpthread t.cpp strace ./a.out
...
bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(0.0.0.0)},
16) = 0
...
http://downloads.sourceforge.net/asio/asio-0.3.9.tar.bz2?modtime=1197163255big_mirror=0
#include asio.hpp
class server
{
public:
server(asio::io_service);
asio::ip::tcp::acceptor acceptor_;
};
server::server(asio::io_service io_service):
acceptor_(io_service,
asio::ip::tcp::endpoint(asio::ip::tcp::v4(), 2711))
{
}
int main()
{
asio::io_service io_service;
server s(io_service);
return 0;
}
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian
4.3-20080127-1)
--
Summary: Integer variable value lost due to optimizations?
Product: gcc
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
[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=35057
[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 CC||olafvdspek at gmail dot com 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 #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/cgi-bin/bugreport.cgi?bug=455199 Package: g++-4.3 Version: 4.3-20071130-1 Severity: normal Hi, ext/hash_set is deprecated in 4.3, but it's replacement, unordered_set doesn't appeart to be available in 4.2. Using unordered_set doesn't sound like a good plan (at the moment), so wouldn't it make sense to postpone the deprecation until it's replacement has been available for some time? The extreme would be to wait until 4.3 is in oldstable. Greetings, Olaf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
