public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible
@ 2009-04-17 14:26 ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: ian at airs dot com @ 2009-04-17 14:26 UTC (permalink / raw)
To: gcc-bugs
libstdc++ ensures that cin/cout/cerr are constructed before they are used, but
the scheme fails when using constructor priorities. Constructors with a
priority are run before constructors without a priority, which is the
appropriate behaviour. However, this means that this program:
#include <iostream>
void f1() __attribute__ ((constructor (101)));
void f1() { std::cout << "f1" << std::endl; }
int main() { }
will crash at runtime. f1 will be run at a user level priority, but it will
run before std::cout is initialized.
I suggest that on systems which support constructor priorities, that we arrange
to run ios_base::Init::Init() at a high priority. The destructor should also
be run at a high priority, of course.
--
Summary: cin/cout/cerr constructors should run at high priority
when possible
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible ian at airs dot com
@ 2009-04-17 15:06 ` paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 7+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-17 15:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from paolo dot carlini at oracle dot com 2009-04-17 15:06 -------
I see. I would be tempted to ask you to propose a fix at once, seems pretty
simple, basically a bit of configury and very few lines of actual code.
However, I wonder if we have something similar elsewhere, I seem to remember
something for the memory allocators, for example, but possibly by now we have
static locals everywhere to avoid completely running into such priority issues.
Another area which probably should be audited is that of locale. What do you
think?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
@ 2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 7+ messages in thread
From: ian at airs dot com @ 2009-04-18 5:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from ian at airs dot com 2009-04-18 05:40 -------
You are much more familiar with the library than I am. I don't know if this
issue arises anywhere else. cin/cout/cerr is sort of an obvious case. It
didn't really occur to me that there might be similar issues elsewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
@ 2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 7+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2009-04-21 2:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from bkoz at gcc dot gnu dot org 2009-04-21 02:46 -------
I consider this undefined behaviour, so enhancement is the correct severity.
People wanting to mess with non-standard init order should probably be taking
steps to insure that libstdc++ is initialized first anyway. Not doing so is
arguably a bug..... especially as it's not hard to do:
ie:
#include <iostream>
void f1() __attribute__ ((constructor (101)));
void f1()
{
std::ios_base::Init i;
std::cout << "f1" << std::endl;
}
int main() { }
But anyway........
libstdc++ is currently not using the first 100 slots reserved for the GNU
implementation as per:
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
No efforts or audit have ever been made as to enshrine a specified init order
for libstd++. Locales, mutexes, and __mt_allocator would all have to be scoped
and modified as code is/was changed. I consider this doable, but probably as
much work in the long run as the efforts for symbol versioning. There may be an
advantage to doing this for size reasons, as then <iostream>'s
// For construction of filebuffers for cout, cin, cerr, clog et. al.
static ios_base::Init __ioinit;
could be killed.
If there was some kind of real advantage, I would be more into this whole idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
[not found] <bug-39796-4@http.gcc.gnu.org/bugzilla/>
2012-01-03 16:41 ` redi at gcc dot gnu.org
2022-11-06 16:16 ` cvs-commit at gcc dot gnu.org
@ 2023-02-03 19:49 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-03 19:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vhaisman at gmail dot com
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 62200 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
[not found] <bug-39796-4@http.gcc.gnu.org/bugzilla/>
2012-01-03 16:41 ` redi at gcc dot gnu.org
@ 2022-11-06 16:16 ` cvs-commit at gcc dot gnu.org
2023-02-03 19:49 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-06 16:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:4e4e3ffd10f53ef71696bc728ab40258751a2df4
commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka <ppalka@redhat.com>
Date: Sun Nov 6 11:16:00 2022 -0500
libstdc++: Move stream initialization into compiled library [PR44952]
This patch moves the static object for constructing the standard streams
out from <iostream> and into the compiled library on systems that support
init priorities. This'll mean <iostream> no longer introduces a separate
global constructor in each TU that includes it.
We can do this only if the init_priority attribute is supported because
we need a way to ensure the stream initialization runs first before any
user global initializer, particularly when linking with a static
libstdc++.a.
PR libstdc++/44952
PR libstdc++/39796
PR libstdc++/98108
libstdc++-v3/ChangeLog:
* include/std/iostream (__ioinit): No longer define here if
the init_priority attribute is usable.
* src/c++98/ios_init.cc (__ioinit): Define here instead if
init_priority is usable, via ...
* src/c++98/ios_base_init.h: ... this new file.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
[not found] <bug-39796-4@http.gcc.gnu.org/bugzilla/>
@ 2012-01-03 16:41 ` redi at gcc dot gnu.org
2022-11-06 16:16 ` cvs-commit at gcc dot gnu.org
2023-02-03 19:49 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-01-03 16:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-01-03
Ever Confirmed|0 |1
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-03 16:39:39 UTC ---
http://stackoverflow.com/questions/8708539/order-of-initialization was brought
to my attention, which crashes without messing with init-priority
struct Foo
{
Foo();
}foo;
#include <iostream>
Foo::Foo()
{
std::cout << "Hello World";
}
int main() {}
So I'm confirming this as a valid enhancement.
PR 44952 might lead to a better way to ensure the initialization is done once
as early as possible.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-02-03 19:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-17 14:26 [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
[not found] <bug-39796-4@http.gcc.gnu.org/bugzilla/>
2012-01-03 16:41 ` redi at gcc dot gnu.org
2022-11-06 16:16 ` cvs-commit at gcc dot gnu.org
2023-02-03 19:49 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).