CXXFLAGS_FOR_TARGET and config/mt-gnu
The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be += -D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I missing something?
Re: CXXFLAGS_FOR_TARGET and config/mt-gnu
On Thu, Mar 25, 2010 at 1:31 PM, Ian Lance Taylor wrote: > Doug Semler writes: > >> The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET = >> $(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be += >> -D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot >> override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I >> missing something? > > I think you are right. > > Ian > All right, I opened PR/43538 so that it will be tracked...
Re: static linking on Cygwin
On Fri, Apr 23, 2010 at 5:35 AM, Janus Weil wrote: > I'm redirecting my question here, since it also applies to "gcc > -static" on Cygwin. > > Cheers, > Janus > > > > -- Forwarded message -- > From: Janus Weil > Date: 2010/4/23 > Subject: static linking on Cygwin > To: gfortran > > > Hi all, > > I have just tried the gfortran 4.3.4 build on Cygwin/WinXP (I'm not a > regular Windows/Cygwin user though). > > One thing I noticed is that compiling with -static fails: > > /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: > cannot find -lgcc_ > > It works, however, when adding -static-libgcc. On Linux compiling with > -static works fine, also without -static-libgcc. Can someone explain > this behaviour to me? Is this a feature or a bug? > I was thinking that the cygwin/mingw32/w64-mingw32 ports should follow the same logic that linux does with respect to the shared gcc dll (excepting for the --[no]as-needed linker flags, which isn't needed as all DLLs are --no-as-needed - there's no propogation of depenedency DLLs to the parent on Win32 targets). In order for exception handling to work across dll boundaries, the default should, IMO, imply libgcc_s as it does on other targets, and -static should be explicitly required to turn off the libgcc_s and use libgcc_eh on the Win32 targets. For example, currently exception handling in objective c doesn't work properly if using the runtime as a DLL, since the gcc driver is used to build the objc runtime dll. The g++ driver doesn't suffer this, because using this driver implies -shared-libgcc
libstdc++, generic locale configuration, and c++0x
While investigating a multithread segfault on mingw32 systems, I discovered that the cause of the problem is a data race introduced in the config/locale/generic/c_locale.cc and friends. There are several data races that can occur. Note that these races are INDEPENDENT of the thread safety of setlocale itself. 1) The attempt to save the old locale can fail. If thread 1 assigns to __old, and thread 2 calls setlocale(LC_ALL, "C") before thread 1 is able to memcpy __old to __sav, thread 1's copy can be corrupted because the string can be allocated in static storage. 2) The obvious race between the setting of locale to "C" in thread 1 and thread 2 setting it back to __sav before thread 1 is able to call functions like strtof, etc. Any functions that deal with conversions have this problem. In the past (e.g. PR 6015, 6761, and others), the problems are fixed on the gnu version but not in the generic side, seemingly due to (paraphrasing) concentrating on glibc systems. With respect to c++98, this seems to be a perfectly valid statement. (Although the FAQ is not quite correct in this case, because the FAQ implies that if the C library is thread safe the C++ library is thread safe, which is not true due to the data races). The draft of the c++0x standard, specifically section 17.6.4.8, prohibits data races introduced on globally visible objects directly or indirectly by the standard library, which seems to imply that the behavior of these functions is/will be prohibited. Before I entered a bug I wanted to see if I am actually interpreting this correctly.
Re: libstdc++, generic locale configuration, and c++0x
On Sun, Jun 6, 2010 at 12:03 PM, Paolo Carlini wrote:
>
>> Before I entered a bug I wanted to see if I am actually interpreting
>> this correctly.
>
> Assuming you are, the issue doesn't qualify for Bugzilla, because nobody
> claims to have implemented this section of c++0x.
>
> Paolo
Well, it doesn't look like anyone can ever claim to have "implemented"
the section I pointed out, since this section is requirements on the
library itself.
Regardless, it therefore seems that the claims of thread safety in the
libstdc++ manual are misleading at best and patently false at worst
for any implementation excepting for glibc. The data race exists in
the generic implementation regardless of the platform. This means
that if the program is running in a locale that uses ',' as a radix
character, you can have unknown results if multiple threads attempt to
do:
strstream iss ("111,111 222,222 333,333");
float f;
iss >> f; // the values of f can be undetermined due to race with
setlocale and strtod
// crash can occur due to race between time of
setlocale(LC_ALL, NULL) and memcpy to save it.
So...would you consider this a bug in the documentation, or a bug in
the library? And even if it's a bug in the documentation, it will
eventually have to be fixed for c++0x, yes?
Re: How to pass a pathlist in RUNTESTFLAGS?
On Fri, Jul 9, 2010 at 9:12 AM, IainS wrote: > Hi, > > I want to do this: > > RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/somewhere " > > I've tried escaping the path with \ ' inverting the " and ' .. all to no > avail .. > > what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere .. > > google hasn't helped.. > > anyone know what incantation I've missed? > cheers, > Iain > IIRC i needed something like (can't remember offhand if this is exactly it, but it's something like this...) RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere --target_board=unix/-foo/-bar"
