[Bug other/51054] New: libitm doesn't build on MacOS 10.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51054 Bug #: 51054 Summary: libitm doesn't build on MacOS 10.6 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boost-consulting.com The following command (which works for me with macports gmp,mpfr,and mpc, and a hand-built-from-source libiconv in /usr/local/lib) fails without --disable-libitm. export LDFLAGS=-L/usr/local/lib && ~/src/gcc/configure --enable-languages=c,c++ --disable-libitm --disable-multilib --disable-bootstrap --prefix=/usr/local/stow/gcc-4.7 --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local && gmake -j8 The failure looks like: libtool: compile: /private/tmp/gcc-build/./gcc/xgcc -B/private/tmp/gcc-build/./gcc/ -B/usr/local/stow/gcc-4.7/x86_64-apple-darwin10.8.0/bin/ -B/usr/local/stow/gcc-4.7/x86_64-apple-darwin10.8.0/lib/ -isystem /usr/local/stow/gcc-4.7/x86_64-apple-darwin10.8.0/include -isystem /usr/local/stow/gcc-4.7/x86_64-apple-darwin10.8.0/sys-include -DHAVE_CONFIG_H -I. -I/Users/dave/src/gcc/libitm -I/Users/dave/src/gcc/libitm/config/x86 -I/Users/dave/src/gcc/libitm/config/posix -I/Users/dave/src/gcc/libitm/config/generic -I/Users/dave/src/gcc/libitm -Wall -pthread -Werror -g -O2 -MT sjlj.lo -MD -MP -MF .deps/sjlj.Tpo -c /Users/dave/src/gcc/libitm/config/x86/sjlj.S -fno-common -DPIC -o .libs/sjlj.o /Users/dave/src/gcc/libitm/config/x86/sjlj.S:28:Unknown pseudo-op: .type /Users/dave/src/gcc/libitm/config/x86/sjlj.S:28:Rest of line ignored. 1st junk character valued 95 (_). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:31:Unknown pseudo-op: .cfi_startproc /Users/dave/src/gcc/libitm/config/x86/sjlj.S:36:Unknown pseudo-op: .cfi_def_cfa_offset /Users/dave/src/gcc/libitm/config/x86/sjlj.S:36:Rest of line ignored. 1st junk character valued 56 (8). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:48:Unknown pseudo-op: .cfi_def_cfa_offset /Users/dave/src/gcc/libitm/config/x86/sjlj.S:48:Rest of line ignored. 1st junk character valued 56 (8). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:65:Unknown pseudo-op: .cfi_endproc /Users/dave/src/gcc/libitm/config/x86/sjlj.S:66:Unknown pseudo-op: .size /Users/dave/src/gcc/libitm/config/x86/sjlj.S:66:Rest of line ignored. 1st junk character valued 95 (_). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:70:Unknown pseudo-op: .type /Users/dave/src/gcc/libitm/config/x86/sjlj.S:70:Rest of line ignored. 1st junk character valued 71 (G). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:71:Unknown pseudo-op: .hidden /Users/dave/src/gcc/libitm/config/x86/sjlj.S:71:Rest of line ignored. 1st junk character valued 71 (G). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:74:Unknown pseudo-op: .cfi_startproc /Users/dave/src/gcc/libitm/config/x86/sjlj.S:85:Unknown pseudo-op: .cfi_def_cfa /Users/dave/src/gcc/libitm/config/x86/sjlj.S:85:Rest of line ignored. 1st junk character valued 37 (%). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:86:Unknown pseudo-op: .cfi_register /Users/dave/src/gcc/libitm/config/x86/sjlj.S:86:Rest of line ignored. 1st junk character valued 37 (%). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:102:Unknown pseudo-op: .cfi_endproc /Users/dave/src/gcc/libitm/config/x86/sjlj.S:103:Unknown pseudo-op: .size /Users/dave/src/gcc/libitm/config/x86/sjlj.S:103:Rest of line ignored. 1st junk character valued 71 (G). /Users/dave/src/gcc/libitm/config/x86/sjlj.S:105:unknown section type: @progbits gmake[4]: *** [sjlj.lo] Error 1 gmake[4]: Leaving directory `/private/tmp/gcc-build/x86_64-apple-darwin10.8.0/libitm' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/private/tmp/gcc-build/x86_64-apple-darwin10.8.0/libitm' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/private/tmp/gcc-build/x86_64-apple-darwin10.8.0/libitm' gmake[1]: *** [all-target-libitm] Error 2 gmake[1]: Leaving directory `/private/tmp/gcc-build' gmake: *** [all] Error 2 Compilation exited abnormally with code 2 at Wed Nov 9 06:41:48
[Bug c++/51397] New: static_assert message formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51397
Bug #: 51397
Summary: static_assert message formatting
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
I just noticed that GCC can be overly-helpful ;-) when formatting a
static assertion message:
static_assert('X' != '\130',"'X' has the wrong value");
gives me
error: static assertion failed: "\'X\' has the wrong value"
I suggest that GCC should drop the surrounding quotes and not try to
escape any characters in the message. Otherwise, things like
#define static_assert_(x) static_assert(x, #x)
static_assert_('X' != '\130')
turn out quite badly.
The point of this facility is, after all, to help programmers report legible
errors!
[Bug libstdc++/51452] New: has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452
Bug #: 51452
Summary: has_nothrow_.*constructor bugs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
The traits that detect nothrow constructibility are buggy because they are
influenced by whether the object has a nothrow dtor; destruction is invoked at
the end of evaluation of the full expression in the noexcept( ... ) operator.
They all use the pattern of constructing a temporary inside noexcept, whereas
they should be using placement new:
struct X
{
X() noexcept;
~X();
};
static_assert( noexcept( X() ), "fails because of ~X" );
static_assert( noexcept(new (nullptr) X()), "works" );
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #5 from d...@boost-consulting.com 2011-12-07 18:41:12 UTC --- (In reply to comment #1) > I think this is by design, see the thread beginning with c++std-lib-30698 > > I've been surprised by that reasoning several times e.g. > http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html I see the thread. I don't see anything in the thread that supports the idea that it should behave this way, but maybe I'm missing something.
[Bug c++/51478] New: constexpr not doing short-circuit evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51478
Bug #: 51478
Summary: constexpr not doing short-circuit evaluation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
This program should compile, but instead it blows the instantiation stack.
template
constexpr int factorial(int n)
{
return n ? n * factorial(n - 1) : 1;
}
int array[factorial<>(6)];
[Bug c++/49808] New: GCC adds an address-of somewhere!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49808
Summary: GCC adds an address-of somewhere!
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
Compile the following:
template
struct A
{
A() { float r = g(0); }
};
struct f_t
{
float operator() (float x) const { return 1; }
};
f_t f;
A x;
Now replace "g(0)" with "(*g)(0)". It compiles!
It's almost as though I had written
A x;
