Re: [Target maintainers]: Please update libjava/sysdep/*/locks.h with new atomic builtins
Hi,
I've committed the following patch.
It should even perform better since we are able to often get rid of the
instructions extracting the condition code into a register (ipm, srl).
If all targets have been migrated the files probably could be merged?!
Bye,
-Andreas-
2012-06-15 Andreas Krebbel
* sysdep/s390/locks.h (compare_and_swap, release_set)
(read_barrier, write_barrier): Use the GCC atomic builtins.
---
libjava/sysdep/s390/locks.h | 24
1 file changed, 24 modifications(!)
Index: libjava/sysdep/s390/locks.h
===
*** libjava/sysdep/s390/locks.h.orig
--- libjava/sysdep/s390/locks.h
***
*** 1,6
// locks.h - Thread synchronization primitives. S/390 implementation.
! /* Copyright (C) 2002 Free Software Foundation
This file is part of libgcj.
--- 1,6
// locks.h - Thread synchronization primitives. S/390 implementation.
! /* Copyright (C) 2002-2012 Free Software Foundation
This file is part of libgcj.
*** inline static bool
*** 22,42
compare_and_swap(volatile obj_addr_t *addr,
obj_addr_t old, obj_addr_t new_val)
{
! int result;
!
! __asm__ __volatile__ (
! #ifndef __s390x__
! " cs %1,%2,0(%3)\n"
! #else
! " csg %1,%2,0(%3)\n"
! #endif
! " ipm %0\n"
! " srl %0,28\n"
! : "=&d" (result), "+d" (old)
! : "d" (new_val), "a" (addr)
! : "cc", "memory");
!
! return result == 0;
}
// Set *addr to new_val with release semantics, i.e. making sure
--- 22,28
compare_and_swap(volatile obj_addr_t *addr,
obj_addr_t old, obj_addr_t new_val)
{
! return __sync_bool_compare_and_swap (addr, old, new_val);
}
// Set *addr to new_val with release semantics, i.e. making sure
*** compare_and_swap(volatile obj_addr_t *ad
*** 45,51
inline static void
release_set(volatile obj_addr_t *addr, obj_addr_t new_val)
{
! __asm__ __volatile__("bcr 15,0" : : : "memory");
*(addr) = new_val;
}
--- 31,37
inline static void
release_set(volatile obj_addr_t *addr, obj_addr_t new_val)
{
! __sync_synchronize ();
*(addr) = new_val;
}
*** compare_and_swap_release(volatile obj_ad
*** 64,70
inline static void
read_barrier()
{
! __asm__ __volatile__("bcr 15,0" : : : "memory");
}
// Ensure that prior stores to memory are completed with respect to other
--- 50,56
inline static void
read_barrier()
{
! __sync_synchronize ();
}
// Ensure that prior stores to memory are completed with respect to other
*** read_barrier()
*** 72,77
inline static void
write_barrier()
{
! __asm__ __volatile__("bcr 15,0" : : : "memory");
}
#endif
--- 58,63
inline static void
write_barrier()
{
! __sync_synchronize ();
}
#endif
Re: C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC
On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote: > Hello Everyone, > > I thought you might be interested in some C++ expression template > benchmarks I have done. > > http://www.wlandry.net/Projects/FTensor#Benchmarks > > I found that GCC optimized the expression template code better than > unrolling expressions by hand. In fact, GCC was far, far better at > optimizing code with expression templates than any other compiler. I > ran the same benchmarks back in 2003, and GCC has improved quite a lot > since then. Heh, yeah - quite possibly because I myself was working with a POOMA based CFD code during my PhD which made me start working on inproving GCC for expression template code ;) It is btw interesting to try to enable profile-feedback for the compilers - for some compilers you'll see that the profile-generating executables are so slow as to be unusable (as they seem to keep all calls of the expression templates). Thanks, Richard. > > Cheers, > Walter Landry > wlan...@caltech.edu
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Thu, Jun 14, 2012 at 10:33:11PM +0200, Paweł Sikora wrote: > from the others side, someone can use -frecord-gcc-switches to detect mixed > '-std=...' > after final linking and report error in such cases. I don't think -frecord-gcc-switches is useful for that, unless you always specify explicit -std= option, because with -frecord-gcc-switches without the default -std=gnu98 you get nothing in the note section, and as strings are merged with this option, all you can find out is whether there was at least one -std=c++11 or -std=gnu++0x etc. compiled object. If you use -grecord-gcc-switches, you can investigate the command line per translation unit (and find out which was it), of course for this kind of detection you need to limit yourself to DW_AT_language 4 and then look at DW_AT_producer... Jakub
4.7.1 build failure in hppa1.1-hp-hpux11.11
Hi,
I am trying 4.7.1 build for hppa1.1-hp-hpux11.11. Variable SHLIB_MAPFILES is
not set for hppa1.1-hp-hpux11.11 build. This is causing the build failure.
File: .../build/gcc/hppa1.1-hp-hpux11.11/libgcc/Makefile
Generated from: .../gcc_src/libgcc/Makefile.in
GCC 4.7.1 hppa1.1-hp-hpux11.11 configure command:
.../gcc_src/configure --host=hppa1.1-hp-hpux11.11 \
--target=hppa1.1-hp-hpux11.11 --build=hppa1.1-hp-hpux11.11 \
--prefix=.../hp-gcc-4.7.1 --with-gnu-as --without-gnu-ld \
--enable-threads=posix --enable-languages="c,c++" \
--with-gmp=.../hppa1.1-hp-hpux11.11 --with-mpfr=.../hppa1.1-hp-hpux11.11 \
SED=/usr/bin/sed
The Makefile which is causing the problem:
.../gcc_src/libgcc/Makefile.in
899 # Map-file generation.
900 ifneq ($(SHLIB_MKMAP),)
901 libgcc.map: $(SHLIB_MKMAP) $(SHLIB_MAPFILES) $(libgcc-s-objects)
902 { $(NM) $(SHLIB_NM_FLAGS) $(libgcc-s-objects); echo %%; \
903 cat $(SHLIB_MAPFILES) \
904 | sed -e '/^[ ]*#/d' \
905 -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
906 | $(gcc_compile_bare) -E -xassembler-with-cpp -; \
907 } | $(AWK) -f $(SHLIB_MKMAP) $(SHLIB_MKMAP_OPTS) > tmp-$@
908 mv tmp-$@ $@
909 libgcc_s$(SHLIB_EXT): libgcc.map
910 mapfile = libgcc.map
911 endif
The Makefile generated by configure:
.../build/gcc/hppa1.1-hp-hpux11.11/libgcc/Makefile:
899 # Map-file generation.
900 ifneq ($(SHLIB_MKMAP),)
901 libgcc.map: $(SHLIB_MKMAP) $(SHLIB_MAPFILES) $(libgcc-s-objects)
902 { $(NM) $(SHLIB_NM_FLAGS) $(libgcc-s-objects); echo %%; \
903 cat $(SHLIB_MAPFILES) \
904 | sed -e '/^[ ]*#/d' \
905 -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
906 | $(gcc_compile_bare) -E -xassembler-with-cpp -; \
907 } | $(AWK) -f $(SHLIB_MKMAP) $(SHLIB_MKMAP_OPTS) > tmp-$@
908 mv tmp-$@ $@
909 libgcc_s$(SHLIB_EXT): libgcc.map
910 mapfile = libgcc.map
911 endif
I see that for IA64 SHLIB_MAPFILES gets defined in the following method:
.../gcc_src/libgcc/config/ia64/t-ia64-elf:
SHLIB_MAPFILES += $(srcdir)/config/ia64/libgcc-ia64.ver
and there is a corresponding file:
.../gcc_src/libgcc/config/ia64/libgcc-ia64.ver
Should I do something similar for PA as well? Please provide your suggestion.
Regards,
Kannan
RE: 4.7.1 build failure in hppa1.1-hp-hpux11.11
Sorry missed to mention the issue. Since SHLIB_MAPFILES is empty the command
executed in the Makefile becomes:
{ .../build/gcc/./gcc/nm -pg _muldi3_s.o ... emutls_s.o; echo %%; \
cat \
| sed -e '/^[ ]*#/d' \
-e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
| .../build/gcc/./gcc/xgcc ... -E -xassembler-with-cpp -; \
} | gawk -f .../gcc_src/libgcc/mkmap-flat.awk > tmp-libgcc.map
Note that there is no argument to "cat" command.
Regards,
Kannan
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Mailaripillai, Kannan Jeganathan
Sent: Friday, June 15, 2012 2:38 PM
To: gcc@gcc.gnu.org
Subject: 4.7.1 build failure in hppa1.1-hp-hpux11.11
Hi,
I am trying 4.7.1 build for hppa1.1-hp-hpux11.11. Variable SHLIB_MAPFILES is
not set for hppa1.1-hp-hpux11.11 build. This is causing the build failure.
File: .../build/gcc/hppa1.1-hp-hpux11.11/libgcc/Makefile
Generated from: .../gcc_src/libgcc/Makefile.in
GCC 4.7.1 hppa1.1-hp-hpux11.11 configure command:
.../gcc_src/configure --host=hppa1.1-hp-hpux11.11 \
--target=hppa1.1-hp-hpux11.11 --build=hppa1.1-hp-hpux11.11 \
--prefix=.../hp-gcc-4.7.1 --with-gnu-as --without-gnu-ld \
--enable-threads=posix --enable-languages="c,c++" \
--with-gmp=.../hppa1.1-hp-hpux11.11 --with-mpfr=.../hppa1.1-hp-hpux11.11 \
SED=/usr/bin/sed
The Makefile which is causing the problem:
.../gcc_src/libgcc/Makefile.in
899 # Map-file generation.
900 ifneq ($(SHLIB_MKMAP),)
901 libgcc.map: $(SHLIB_MKMAP) $(SHLIB_MAPFILES) $(libgcc-s-objects)
902 { $(NM) $(SHLIB_NM_FLAGS) $(libgcc-s-objects); echo %%; \
903 cat $(SHLIB_MAPFILES) \
904 | sed -e '/^[ ]*#/d' \
905 -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
906 | $(gcc_compile_bare) -E -xassembler-with-cpp -; \
907 } | $(AWK) -f $(SHLIB_MKMAP) $(SHLIB_MKMAP_OPTS) > tmp-$@
908 mv tmp-$@ $@
909 libgcc_s$(SHLIB_EXT): libgcc.map
910 mapfile = libgcc.map
911 endif
The Makefile generated by configure:
.../build/gcc/hppa1.1-hp-hpux11.11/libgcc/Makefile:
899 # Map-file generation.
900 ifneq ($(SHLIB_MKMAP),)
901 libgcc.map: $(SHLIB_MKMAP) $(SHLIB_MAPFILES) $(libgcc-s-objects)
902 { $(NM) $(SHLIB_NM_FLAGS) $(libgcc-s-objects); echo %%; \
903 cat $(SHLIB_MAPFILES) \
904 | sed -e '/^[ ]*#/d' \
905 -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
906 | $(gcc_compile_bare) -E -xassembler-with-cpp -; \
907 } | $(AWK) -f $(SHLIB_MKMAP) $(SHLIB_MKMAP_OPTS) > tmp-$@
908 mv tmp-$@ $@
909 libgcc_s$(SHLIB_EXT): libgcc.map
910 mapfile = libgcc.map
911 endif
I see that for IA64 SHLIB_MAPFILES gets defined in the following method:
.../gcc_src/libgcc/config/ia64/t-ia64-elf:
SHLIB_MAPFILES += $(srcdir)/config/ia64/libgcc-ia64.ver
and there is a corresponding file:
.../gcc_src/libgcc/config/ia64/libgcc-ia64.ver
Should I do something similar for PA as well? Please provide your suggestion.
Regards,
Kannan
Re: "self" keyword
On 14 June 2012 22:42, Oleg Endo wrote:
> On Thu, 2012-06-14 at 16:34 -0400, Rick C. Hodgin wrote:
>> David,
>>
>> Well, I probably don't have a NEED for it. I've gotten along for 25+
>> years without it. :-)
>>
>> However, what prompted my inquiry is using it would've saved me tracking
>> down a few bugs in recent weeks. Some prior code was re-used for a
>> similar function, but the name of the recursive calls weren't updated in
>> every case. It didn't take long to debug, but I realized that had it
>> always been written as self() it never would've been an issue.
>>
>> I can also see a use for generated code where there's a base source code
>> template in use with an embedded include file reference that changes as
>> it's generated per pass, such as:
>>
>> int step1(int a, int b)
>> {
>> #include "\current_task\step1.cpp"
>> }
>>
>> int step2(int a, int b)
>> {
>> #include "\current_task\step2.cpp"
>> }
>>
>> Using the self() reference for recursion, one could modify stepN.cpp's
>> generator algorithms without having to know or care anything in the
>> wrapper code.
>
> Wouldn't this do?
>
> #define __self__ step1
> int __self__ (int a, int b)
> {
> #include "something"
> __self__ (x, y);
> }
> #undef __self__
You can already do this with GCC in C and C++ (minus problems with
overloaded functions) like this:
#define DECLSELF(f,self) __typeof__ (&f) self = f
int foo (int n)
{
DECLSELF(foo, self);
if (n == 0)
return 0;
else
{
return 1 + self (n - 1);
}
}
--
VZ
Re: "self" keyword
That would work. Yet now I'm back to remembering to update that line of code
equating self to its function name at each use.
My desire for "self" as a keyword is in looking for a way to use contextual
information the compiler already knows about and can easily employ.
Best regards,
Rick C. Hodgin
Original Message
From: Václav Zeman
Sent: Fri, Jun 15, 2012 08:08 AM
To: Oleg Endo
CC: Rick C. Hodgin ; David Brown
; Joe Buck ; Ian Lance
Taylor ; gcc@gcc.gnu.org
Subject: Re: "self" keyword
>On 14 June 2012 22:42, Oleg Endo wrote:
>> On Thu, 2012-06-14 at 16:34 -0400, Rick C. Hodgin wrote:
>>> David,
>>>
>>> Well, I probably don't have a NEED for it. I've gotten along for 25+
>>> years without it. :-)
>>>
>>> However, what prompted my inquiry is using it would've saved me tracking
>>> down a few bugs in recent weeks. Some prior code was re-used for a
>>> similar function, but the name of the recursive calls weren't updated in
>>> every case. It didn't take long to debug, but I realized that had it
>>> always been written as self() it never would've been an issue.
>>>
>>> I can also see a use for generated code where there's a base source code
>>> template in use with an embedded include file reference that changes as
>>> it's generated per pass, such as:
>>>
>>> int step1(int a, int b)
>>> {
>>> #include "\current_task\step1.cpp"
>>> }
>>>
>>> int step2(int a, int b)
>>> {
>>> #include "\current_task\step2.cpp"
>>> }
>>>
>>> Using the self() reference for recursion, one could modify stepN.cpp's
>>> generator algorithms without having to know or care anything in the
>>> wrapper code.
>>
>> Wouldn't this do?
>>
>> #define __self__ step1
>> int __self__ (int a, int b)
>> {
>> #include "something"
>> __self__ (x, y);
>> }
>> #undef __self__
>You can already do this with GCC in C and C++ (minus problems with
>overloaded functions) like this:
>
>#define DECLSELF(f,self) __typeof__ (&f) self = f
>
>int foo (int n)
>{
>DECLSELF(foo, self);
>
>if (n == 0)
>return 0;
>else
>{
>return 1 + self (n - 1);
>}
>}
>
>--
>VZ
unrecognizable insn.
Hi,
I'm trying to expand a builtin functions into assembles, with
processing a little bit for the operands.
Like for the builtin function:
tcreate (arg0, arg1, arg2)
I'm trying to generate the assemble code (pseudo):
TCREATE arg0<<32|arg1, arg2
but I got the following error:
-
fib.c:38:1: error: unrecognizable insn:
(insn 15 14 16 4 (set (reg:DI 100)
(ashift:DI (reg:DI 100)
(const_int 32 [0x20]))) fib.c:25 -1
(nil))
-
Not sure why this happens,
Here is the related source code for generating this insn:
switch (fcode)
{
case BUILT_IN_WSTREAM_DF_TCREATE:
arg0 = CALL_EXPR_ARG (exp, 0);
arg1 = CALL_EXPR_ARG (exp, 1);
arg2 = CALL_EXPR_ARG (exp, 2);
op0 = expand_normal (arg0);
op1 = expand_normal (arg1);
op2 = expand_normal (arg2);
op0 = copy_to_mode_reg (DImode,op0);
insn = emit_move_insn (op0, gen_rtx_ASHIFT (DImode, op0, GEN_INT (32)));
insn = emit_insn (gen_rtx_SET (VOIDmode, op0,
gen_rtx_PLUS (DImode, op0, op1)));
insn = emit_insn (gen_tstar_write (op2,op0,op2));
... ...
Any ideas?
Thanks,
Feng
Re: RA best is NO_REGS
The output is still the same but the spill is fixed in 4.7.1. On 14/06/12 13:47, Paulo J. Matos wrote: Hi, I found a problem with my port where IRA generates a spill error. After looking at the logs I get this kind of output for the best class for the pseudo regs: Pass 0 for finding pseudo/allocno costs a2 (r30,l0) best NO_REGS, allocno NO_REGS a3 (r29,l0) best NO_REGS, allocno NO_REGS a4 (r28,l0) best NO_REGS, allocno NO_REGS a5 (r27,l0) best NO_REGS, allocno NO_REGS a0 (r26,l0) best XL_REG, allocno XL_REG a1 (r20,l0) best AL_REG, allocno AL_REG This doesn't look good. Why NO_REGS? Cheers, -- PMatos
Re: [Target maintainers]: Please update libjava/sysdep/*/locks.h with new atomic builtins
On Fri, Jun 15, 2012 at 3:32 AM, Andreas Krebbel wrote: > If all targets have been migrated the files probably could be merged?! Yes, it looks like most targets could use a generic implementation, but the generic implementation should be based on the __atomic intrinsics, not the __sync intrinsics, because the latter always uses strict memory model semantics although the locks allow weaker semantics. - David
Re: GCC 4.7.1 Released
good job! On Jun 14, 2012, at 5:45 AM, Richard Guenther wrote: > > The GNU Compiler Collection version 4.7.1 has been released. > > GCC 4.7.1 is the first bug-fix release containing important fixes > for regressions and serious bugs in GCC 4.7.0 with over 100 bugs > fixed since the previous release. This release is available from > the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! > > ___ > GNU Announcement mailing list > https://lists.gnu.org/mailman/listinfo/info-gnu
Re: RFH - Testing targets for the switch to C++
On Tue, Apr 10, 2012 at 3:07 AM, Diego Novillo wrote: > On 4/10/12 9:04 AM, NightStrike wrote: >> >> On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo wrote: >> >>> My plea for help is to everyone who has access to the targets >>> mentioned in the list: please follow the instructions in that page and >>> fill-in the table entries of the targets that you tested. >>> >>> If you see a missing target that should be tested, by all means, add >>> it to the list. >> >> >> I will test all of the mingw-w64 host/target combinations once trunk >> doesn't cause an ICE again (should be soon with Kai's recent patch). >> I'll add them to your list as I test them. > > > Excellent, thanks. Took me a while, but I built a linux to win64 cross compiler using --enable-build-with-cxx. How do I verify that the compiler was actually built with g++? ldd on the gcc binary?
Re: RFH - Testing targets for the switch to C++
On 12-06-15 12:42 , NightStrike wrote: Took me a while, but I built a linux to win64 cross compiler using --enable-build-with-cxx. Thanks. How do I verify that the compiler was actually built with g++? ldd on the gcc binary? That would work, yes. But do it on stage1-gcc/xgcc. The binaries in stage2-gcc/ and gcc/ are always built with C++. Diego.
Re: unrecognizable insn.
Feng LI writes:
> I'm trying to expand a builtin functions into assembles, with
> processing a little bit for the operands.
>
> Like for the builtin function:
> tcreate (arg0, arg1, arg2)
> I'm trying to generate the assemble code (pseudo):
> TCREATE arg0<<32|arg1, arg2
>
> but I got the following error:
> -
> fib.c:38:1: error: unrecognizable insn:
> (insn 15 14 16 4 (set (reg:DI 100)
> (ashift:DI (reg:DI 100)
> (const_int 32 [0x20]))) fib.c:25 -1
> (nil))
> -
>
> Not sure why this happens,
>
> Here is the related source code for generating this insn:
>
> switch (fcode)
> {
> case BUILT_IN_WSTREAM_DF_TCREATE:
> arg0 = CALL_EXPR_ARG (exp, 0);
> arg1 = CALL_EXPR_ARG (exp, 1);
> arg2 = CALL_EXPR_ARG (exp, 2);
>
> op0 = expand_normal (arg0);
> op1 = expand_normal (arg1);
> op2 = expand_normal (arg2);
>
> op0 = copy_to_mode_reg (DImode,op0);
> insn = emit_move_insn (op0, gen_rtx_ASHIFT (DImode, op0, GEN_INT (32)));
> insn = emit_insn (gen_rtx_SET (VOIDmode, op0,
>gen_rtx_PLUS (DImode, op0, op1)));
> insn = emit_insn (gen_tstar_write (op2,op0,op2));
> ... ...
>
> Any ideas?
Rather than building the shift by hand like this, do something like
val = expand_simple_binop (DImode, ASHIFT, op0, GEN_INT (32), op0,
1, OPTAB_DIRECT);
Ian
Re: RFH - Testing targets for the switch to C++
On Fri, Jun 15, 2012 at 7:24 AM, Diego Novillo wrote: > On 12-06-15 12:42 , NightStrike wrote: > >> Took me a while, but I built a linux to win64 cross compiler using >> --enable-build-with-cxx. > > > Thanks. > > >> How do I verify that the compiler was >> actually built with g++? ldd on the gcc binary? > > > That would work, yes. But do it on stage1-gcc/xgcc. The binaries in > stage2-gcc/ and gcc/ are always built with C++. Looks like it worked. The testsuite is still running (under wine). For reference, this target is x86_64-w64-mingw32.
Re: C++98/C++11 ABI compatibility for gcc-4.7
> It seems to be an inadvertent incompatibility caused by the > interaction of a libstdc++ workaround for a bug and g++ behaviour that > may not have been known to the libstdc++ devs, so not something that > could have been prevented by making it a linker error, because noone > knew it was even broken. Testing and reporting bugs and analysing the > problem should lead to it being fixed. I think the problem was GCC > devs not knowing the problem existed, rather than not taking it > seriously. Whether or not this particular incompatibility was intended or not, the point remains. You cannot say that GCC devs are taking the C++11 binary incompatibility issue seriously while: a) there exist serious ABI incompatibilities between the modes. b) there is essentially no notice to users about the problem (and lots of users already brokenly compiling in C++11 mode!) c) there are no recommendations or plans for how users and distros are expected to deal with the issue. I am happy to see that Matthias has also recently noted this issue from the point of view of a distribution. But I'm *quite* surprised to see that even now it is apparently a surprise to some on this very list that there is such an incompatibility! When I noted the std::list incompatibility back last October when it was introduced (on http://gcc.gnu.org/PR49561), the response was quite clear that there is no expectation of compatibility between the modes, and never was. When I tried to ask some of these same questions last November (in the "Long-term plan for C++98/C++11 incompatibility" thread), the answer I heard there seemed to me to be ~"distros should just provide two sets of libraries, not our problem". IMO, at the /very least/, libstdc++ should go ahead and change std::string to be the new implementation. Once std::string is ABI-incompatible between the modes, there's basically no chance that anyone would think that linking things together from the two modes is a good thing to try, for more than a couple minutes.
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: > IMO, at the /very least/, libstdc++ should go ahead and change std::string > to be the new implementation. Once std::string is ABI-incompatible between > the modes, there's basically no chance that anyone would think that > linking things together from the two modes is a good thing to try, for > more than a couple minutes. > Agreed. -- Gaby
Re: C++98/C++11 ABI compatibility for gcc-4.7
Hi, > On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: > >> IMO, at the /very least/, libstdc++ should go ahead and change std::string >> to be the new implementation. Once std::string is ABI-incompatible between >> the modes, there's basically no chance that anyone would think that >> linking things together from the two modes is a good thing to try, for >> more than a couple minutes. >> > > Agreed. Seconded. I find the idea simple but cute. Paolo > Ps: I'm not volunteering to do the actual work ;) kidding, sooner or later have to do it anyway. Just not right *now*. I could do it in a couple of weeks, definitely in time for 4.8.
typos in http://gcc.gnu.org/wiki/CppConventions
They clause client code taking the address => cause structs adn classes => and
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Fri, Jun 15, 2012 at 10:52:27PM +0200, Paolo Carlini wrote: > Hi, > > > On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: > > > >> IMO, at the /very least/, libstdc++ should go ahead and change std::string > >> to be the new implementation. Once std::string is ABI-incompatible between > >> the modes, there's basically no chance that anyone would think that > >> linking things together from the two modes is a good thing to try, for > >> more than a couple minutes. > >> > > > > Agreed. > > Seconded. I find the idea simple but cute. I strongly agree. > > Paolo > > > > > Ps: I'm not volunteering to do the actual work ;) kidding, sooner or later > have to do it anyway. Just not right *now*. I could do it in a couple of > weeks, definitely in time for 4.8. Does this basically mean that compiling C++ code with GCC4.7 will be playing Russian roulette? Gabriel
Re: typos in http://gcc.gnu.org/wiki/CppConventions
On 15 June 2012 21:56, Jay K wrote: > > They clause client code taking the address > > => cause > > > > > > > > structs adn classes > => and So fix them, it's a wiki.
Re: C++98/C++11 ABI compatibility for gcc-4.7
Hi, > Does this basically mean that compiling C++ code with GCC4.7 will be playing > Russian roulette? I don't know, I see pretty extreme statements around, which lately (maybe because I'm getting older? ;) I do my best to avoid. In any case, 4.7.1 is already out, whatever we do as regards to rolling out a completely new std::string implementation doesn't seem suited for a .2 release. Just my vote. Paolo
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 15 June 2012 22:23, Gabriel Paubert wrote: > > Does this basically mean that compiling C++ code with GCC4.7 will be playing > Russian roulette? No. If you don't use -std=c++11 then there's absolutely no problem whatsoever. If you do use it, use it consistently.
libatomic -Werror problem
I am running into a problem building a multilib version of libatomic. Because of how I configure GCC (building the mips-linux-gnu target with the --with-synci option) some compilations will always generate a warning while compiling the libatomic files. See http://gcc.gnu.org/ml/gcc/2012-06/msg00100.html for details. This causes the libatomic build to fail because it is compiled with -Werror which is added in the configure script. None of the other libraries seem to be built with -Werror. Can we take this out? Or should it be replaced by AC_PROG_CPP_WERROR? I looked at the definition of AC_PROG_CPP_WERROR in config/acx.m4 and I see it sets ac_c_preproc_warn_flag to 'yes' but it is not clear to me what affect that has in the configure script, if any. I would be happy to submit a patch for this, I am just not sure what the right fix is. Steve Ellcey sell...@mips.com
gcc-4.6-20120615 is now available
Snapshot gcc-4.6-20120615 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120615/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 188682 You'll find: gcc-4.6-20120615.tar.bz2 Complete GCC MD5=ea5ca03ef7e3d5fceded4823c93e77a3 SHA1=31410e5815029bfbf45ed4a9b374a75c7392619c Diffs from 4.6-20120608 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: typos in http://gcc.gnu.org/wiki/CppConventions
On 15 June 2012 22:58, Jay K wrote: > I saw it said "ummutable page". > I'll check again. You need to be logged in to edit anything on the wiki, but anyone can create a user and log in.
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Fri, Jun 15, 2012 at 4:23 PM, Gabriel Paubert wrote: > Does this basically mean that compiling C++ code with GCC4.7 will be playing > Russian roulette? I don't think so. Let's make sure we do not overstate the case and we keep things in perspective and accurate. -- Gaby
