[Bug libstdc++/81469] New: std::uncaught_exception should be marked as deprecated for C++1z

2017-07-17 Thread daniel.gutson at intel dot com
Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at intel dot com Target Milestone: --- I think that in C++1z/17, std::uncaught_exception should be marked as [[deprecated]].

[Bug c++/80785] New: warning for static definitions inside extern "C"

2017-05-16 Thread daniel.gutson at intel dot com
Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at intel dot com Target Milestone: --- The following code is contradictory, with some probability that the programmer made is wrongly assuming something: extern "C" { static int x = 1

[Bug c++/80785] warning for static definitions inside extern "C"

2017-05-16 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80785 --- Comment #2 from Daniel Gutson --- (In reply to Jonathan Wakely from comment #1) > (In reply to Daniel Gutson from comment #0) > > I don't see why one would want to do this. > > You might have a header that encloses the entire contents in an

[Bug c++/80785] warning for static definitions inside extern "C"

2017-05-16 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80785 --- Comment #4 from Daniel Gutson --- (In reply to Jonathan Wakely from comment #3) > The usual reason a header has extern "C" is because it's intended for use by > both C and C++ programs, and in that case restructuring it for the benefit > of C

[Bug c/80154] New: sizeof(long double) == 16 even with -mlong-double-80

2017-03-22 Thread daniel.gutson at intel dot com
Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at intel dot com Target Milestone: --- On a x86_64 linux machine, both sizeof(long double) and sizeof(__float80) return 16, despite specifying -mlong-double-80 (x86 gcc). Other options that did not change

[Bug target/80154] sizeof(long double) == 16 even with -mlong-double-80

2017-03-22 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80154 --- Comment #3 from Daniel Gutson --- Documentation is confusing: -m96bit-long-double -m128bit-long-double These switches control the size of "long double" type. ... -mlong-double-64 -mlong-double-80

[Bug middle-end/69976] Zero the local stack on function exit

2016-09-28 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 --- Comment #11 from Daniel Gutson --- Any update on this?

[Bug preprocessor/71851] New: Get more time granularity at preprocessing

2016-07-12 Thread daniel.gutson at intel dot com
: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at intel dot com Target Milestone: --- I'm proposing to add either an __EXTENDED_TIME__ predefined macro which has the form "HH:MM:SS.xxx" where xxx are the milliseconds, or a predef

[Bug preprocessor/71851] Get more time granularity at preprocessing

2016-07-13 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #5 from Daniel Gutson --- The idea is that the macro expands always to the same value. The final usage of this facility should not be of any matter to gcc, it will be just another program. This macro would change break reproduceabilit

[Bug preprocessor/71851] Get more time granularity at preprocessing

2016-07-13 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #6 from Daniel Gutson --- (In reply to Richard Biener from comment #3) > (In reply to Jakub Jelinek from comment #2) > > Any kind of such code goes strongly against build reproduceability, > > -fcompare-debug etc., so not sure it woul

[Bug preprocessor/71851] Get more time granularity at preprocessing

2016-07-13 Thread daniel.gutson at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #8 from Daniel Gutson --- (In reply to Jakub Jelinek from comment #7) > (In reply to Daniel Gutson from comment #5) > > This macro would change break reproduceability as much as __TIME__ does. > > __TIME__ is now being warned on if r