[Bug libstdc++/81469] New: std::uncaught_exception should be marked as deprecated for C++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81469 Bug ID: 81469 Summary: std::uncaught_exception should be marked as deprecated for C++1z Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal 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"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80785
Bug ID: 80785
Summary: warning for static definitions inside extern "C"
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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;
}
I don't see why one would want to do this.
Of course this could be filed as feature request or enhancement.
[Bug c++/80785] warning for static definitions inside extern "C"
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 extern "C"
> language linkage block, and it might contain static variables.
>
> Variables with internal linkage don't have language linkage, so the extern
> "C" doesn't do anything, but isn't necessarily a mistake.
I still think that a warning would help. With this aid, the programmer may pull
the static definitions out of the extern"C" block, or more importantly,
refactor the organization of the header files structure. Opt-in -Wextern-static
or alike?
>
> For function definitions it's not contradictory, and not redundant:
>
> extern "C" static void f() { }
> static void g() { }
>
> f() and g() both have internal linkage, but have different types. This
> matters if you want to pass &f to a function that takes a pointer to a
> function with "C" language linkage (N.B. GCC and many other compilers don't
> implement this correctly, see PR 2316).
OK, didn't think about this use case.
[Bug c++/80785] warning for static definitions inside extern "C"
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++ only is probably not very likely. But then static variables in > headers aren't terribly common anyway, so maybe it's not a problem. I agree and acknowledge that a header having extern "C" is for including it from C and C++ files. I just ran into this issue from a real life situation, where the header file was a mess mixing static data intended to be "private/local" declarations for only one of the including files, which was exactly what had to be refactored. A warning that detects static declarations inside an extern "C" would evidence this messy situation, triggering the necessary refactor. It could be, as mentioned, an opt-in warning for projects where this case would be considered a design or implementation flaw.
[Bug c/80154] New: sizeof(long double) == 16 even with -mlong-double-80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80154 Bug ID: 80154 Summary: sizeof(long double) == 16 even with -mlong-double-80 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 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 the result: -std=c99 (despite -m is backend), -msoft-float
[Bug target/80154] sizeof(long double) == 16 even with -mlong-double-80
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 -mlong-double-128 These switches control the size of "long double" type. Note that both option families are referred the same in the man page (didn't check the manual). None of these options refer to storage. I guess what I would need is something like -m80bit-long-double. Anyway I suggest to clarify the differences of these two families of options, and if at ever possible, add new ones with more distinct names turning the existing ones obsolete for future versions. In short, please confirm that requiring gcc to store 80-bits precision floating point types into 10 bytes is not possible. Thanks.
[Bug middle-end/69976] Zero the local stack on function exit
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 Bug ID: 71851 Summary: Get more time granularity at preprocessing Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: 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 predefined macro that expands to an integral constant representing milliseconds passed after 00:00:00 hs. One usage of this enhancement is to seed randomization abilities during compile time (i.e. using template metaprogramming). If OK please assign this to me.
[Bug preprocessor/71851] Get more time granularity at preprocessing
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 reproduceability as much as __TIME__ does. IOW, just another predefined macro that will be used in the program. Anecdotically it will be used for randomization seeding. Richard, what would __RANDOM__ expand to? Please see that I try to maintain separated the use case from the functionality, a functionality that is already present (getting time during preprocessing but with more precision).
[Bug preprocessor/71851] Get more time granularity at preprocessing
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 would be really appreciated, it is a
> > direction against various changes done in gcc lately.
> > I think if you need something like that just pass
> > -DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
> > $1}'`
> > or something similar.
>
> I think he wants to have a new random value each time __RANDOM is "evaluated"
> (during C++ template instantiation - thus a preprocessor macro isn't really
> apppropriate).
Actually I don't. As I mention in my last comment, the macro should have the
same value during all compilation. I already wrote a compile-time PRNG (and
another layer that uses it), but please don't get biased by this fact.
[Bug preprocessor/71851] Get more time granularity at preprocessing
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 requested (-Wdate-time), and can be > changed > through environment variables - SOURCE_DATE_EPOCH env var - and for > -fcompare-debug SOURCE_DATE_EPOCH is set by the driver for both invocations > the same. > So, as you can see, there is a strong shift away from __DATE__/__TIME__. OK, granted. I complain that build reproduceability is a specific requirement for a particular audience of users; other users may need just the opposite and IMVHO I think have the same right to claim it. This is of course a dead end discussion we won't have here. We will implement this as a cpp plugin, so feel free to close the issue.
