[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23
08:13:11 UTC ---
When I rebuild libtsan with -fPIE instead of -fPIC in the Makefile, and
g++ -shared -Wl,--whole-archive -o libtsanx.so libtsan.a -ldl -lpthread
(note that .libs/*.o are still built with -fPIC because libtool overrides those
flags and adds its -fPIC at the end), then this link fails with:
/usr/bin/ld: libtsan.a(tsan_rtl.o): relocation R_X86_64_TPOFF32 against
`_ZN6__tsan22cur_thread_placeholderE' can not be used when making a shared
object; recompile with -fPIC
libtsan.a(tsan_rtl.o): could not read symbols: Bad value
collect2: error: ld returned 1 exit status
(obviously, local-exec model would need to patch the insn at dynamic linking
time, making the library DT_TEXTREL (not acceptable for SELinux, not allowed
for x86_64 at all)).
Yes, I see the code generation differences, but the functions are huge anyway,
is it really so crucial that you'd want to make another libtsan_pie.a for it?
BTW, the tsan that was added to GCC yesterday doesn't have
-ftls-model=initial-exec even, so it is even slower.
-ftls-model=initial-exec can only be done for *-*-linux* targets btw, I don't
think other dynamic linkers support dlopening IE model shared libraries.
E.g. libgomp has in its configure.tgt
if test $gcc_cv_have_tls = yes ; then
case ${target} in
*-*-linux*)
XCFLAGS=${XCFLAGS} -ftls-model=initial-exec
;;
esac
fi
so libsanitizer/configure.tgt would need to add it to say TSAN_CXXFLAGS var
that would be substituted by configure.
Would be nice if you could check the numerous warnings from tsan build, e.g. it
seems the ALWAYS_INLINE macro doesn't include the inline keyword, and you are
using it on functions that don't have inline keyword, which gives a warning and
if it is inlined, it is by pure luck. Either you should add inline keywords
manually, or put inline keyword into ALWAYS_INLINE macro. There are other
warnings...
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 08:20:40 UTC --- Have you considered using __builtin_expect to help the compiler in the performance sensitive code? Or even better would be profile-feedback, build libtsan once, run some benchmark, build libtsan again.
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #26 from Dmitry Vyukov dvyukov at google dot com 2012-11-23 08:34:52 UTC --- (In reply to comment #25) Have you considered using __builtin_expect to help the compiler in the performance sensitive code? Or even better would be profile-feedback, build libtsan once, run some benchmark, build libtsan again. There are few of them in the code in the obvious cases. The performance is very shaky and depends on compiler, compiler version and options. I remember I get worse results when I added some other likily/unlikely. I didn't have time for more comprehensive investigation. FDO may be a good idea for prebuild libraries.
[Bug sanitizer/55435] [asan] implement an attribute to disable asan instrumentation for a particular function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55435 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 09:02:34 UTC --- Author: jakub Date: Fri Nov 23 09:02:28 2012 New Revision: 193748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193748 Log: PR sanitizer/55435 * c-common.c (handle_no_address_safety_analysis_attribute): New function. (c_common_attribute_table): Add no_address_safety_analysis. * asan.c (gate_asan): Don't instrument functions with no_address_safety_analysis attribute. (gate_asan_O0): Use !optimize gate_asan (). * doc/extend.texi (no_address_safety_analysis): Document new function attribute. * c-c++-common/asan/attrib-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/attrib-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 09:14:18 UTC --- If we want to support this (I'm actually surprised we just don't error on this), then all users of int_bit_position needs to be guarded with host_integerp (bit_position (), 0). Some of them are, e.g. dwarf2out.c, expr.c, others aren't (devirt in ipa-prop.c/gimple-fold.c, tree-sra.c e.g.).
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-23 10:08:54 UTC --- Author: gjl Date: Fri Nov 23 10:08:49 2012 New Revision: 193749 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193749 Log: PR testsuite/52641 * gcc.dg/unroll_5.c: Add dg-require-effective-target int32plus. * gcc.dg/pr55150-1.c: Same. * gcc.dg/torture/pr54894.c: Add size32plus. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr55150-1.c trunk/gcc/testsuite/gcc.dg/torture/pr54894.c trunk/gcc/testsuite/gcc.dg/unroll_5.c
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #27 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 10:47:14 UTC --- is it really so crucial that you'd want to make another libtsan_pie.a for it? I would actually prefer to have *only* libtsan_pie.a, and not bother with .so version at all. This is what we have in clang land.
[Bug c++/55446] New: array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446
Bug #: 55446
Summary: array new with size zero vanishes from object code
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
The following program compiles successfully and outputs nothing at all. In
fact, the generated assembly has an empty main. This happens even when
compiling with -O0.
#include iostream
struct S {
S() { }
};
int main()
{
std::cout new S[0] bla std::endl;
}
$ g++ new-opt.cc -Wall -Wextra
$ ./a.out
(no output)
The issue goes away when removing the default constructor of S. It seems gcc
believes array-new with zero size is undefined behavior and thus removes the
rest of the expression. I can't follow the undefined behavior part;
array-new with zero size should yield a non-zero pointer (see 3.7.3.1p2
[basic.stc.dynamic.allocation] and 5.3.4p7 [expr.new]).
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 10:56:44 UTC --- Not that today's upstream tsan sources don't link with -fPIC at all because our assembly blobs are not PIC-friendly. /usr/bin/ld: .libs/tsan_rtl_thread.o: relocation R_X86_64_PC32 against undefined symbol `__tsan_trace_switch_thunk' can not be used when making a shared objec Apparently, Wei hacked this around by enabling pure-C++ code, which is slower.
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #28 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 11:14:58 UTC --- Note that today's upstream tsan sources don't link with -fPIC at all because our assembly blobs are not PIC-friendly. /usr/bin/ld: .libs/tsan_rtl_thread.o: relocation R_X86_64_PC32 against undefined symbol `__tsan_trace_switch_thunk' can not be used when making a shared objec Apparently, Wei hacked this around by enabling pure-C++ code, which is slower.
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Bernd Schmidt bernds at gcc dot gnu.org 2012-11-23 12:06:37 UTC --- Fixed.
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #10 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 12:44:14 UTC --- libsanitizer/README.gcc was updated, and libsanitizer/merge.sh was create to help with merges.
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 12:56:57 UTC --- fixed
[Bug debug/55447] New: insufficient debug info for strong typed enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55447
Bug #: 55447
Summary: insufficient debug info for strong typed enum
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pavel.zayt...@oracle.com
For strong typed enum, there is no type and class information.
# cat t.cc
enum class Color : long { red = 200, green = 300 };
int main()
{
Color c;
return 0;
}
#g++ -g -std=c++0x t.cc
10x0025DW_TAG_enumeration_type
DW_AT_name Color
DW_AT_byte_size 0x0004
DW_AT_decl_file 0x0001
DW_AT_decl_line 0x0001
DW_AT_sibling 0x0040
Should have a DW_AT_enum_class and DW_AT_type under DW_TAG_enumeration_type.
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-23 13:08:54 UTC --- A new one: ==2442== Invalid write of size 8 ==2442==at 0x672DF6: iterative_hash_canonical_type(tree_node*, unsigned int) (gimple.c:3170) ==2442==by 0xD3F4A0: htab_find_slot (hashtab.c:712) ==2442==by 0x67DEA8: gimple_register_canonical_type(tree_node*) (gimple.c:3438) ==2442==by 0x4D25C5: uniquify_nodes(data_in*, unsigned int) (lto.c:2050) ==2442==by 0x4D3A0A: lto_main() (lto.c:2089) ==2442==by 0x82195B: compile_file() (toplev.c:545) ==2442==by 0x8235CF: toplev_main(int, char**) (toplev.c:1881) ==2442==by 0x4ECD884: (below main) (libc-start.c:258) ==2442== Address 0x4031e98 is not stack'd, malloc'd or (recently) free'd ==2442==
[Bug target/39102] gcc generating multiple stack stores in optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39102
--- Comment #2 from Jens Maurer jens.maurer at gmx dot net 2012-11-23
14:07:34 UTC ---
Here is another test case:
struct S {
unsigned char * p;
unsigned char * limit;
};
S g(S s);
inline __attribute__((always_inline)) S f(S s, unsigned int n);
S f(S s, unsigned int n)
{
if (__builtin_expect(s.p + n s.limit, 1)) {
s.p += n;
return s;
}
return g(s);
}
extern S sext;
int main()
{
S s = sext;
s = f(s, 4);
s = f(s, 8);
s = f(s, 2);
return (int)(unsigned long)s.p;
}
leading to
movq%rax, (%rsp)
movq%rdx, 8(%rsp)
in the code paths calling g(s), although s is kept in registers throughout.
[Bug debug/54774] insufficient debug info for strong typed enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54774 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 14:49:24 UTC --- *** Bug 55447 has been marked as a duplicate of this bug. ***
[Bug debug/55447] insufficient debug info for strong typed enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55447 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 14:49:24 UTC --- Dup. *** This bug has been marked as a duplicate of bug 54774 ***
[Bug middle-end/55430] [4.8 Regression] LRA miscompilation of ree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 15:13:03 UTC --- Author: jakub Date: Fri Nov 23 15:12:58 2012 New Revision: 193757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193757 Log: PR middle-end/55430 * gcc.dg/pr55430.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55430.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/55448] New: using const-reference SSE or AVX types leads to unnecessary unaligned loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448
Bug #: 55448
Summary: using const-reference SSE or AVX types leads to
unnecessary unaligned loads
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org
The following testcase:
#include immintrin.h
static inline __m256 add(const __m256 a, const __m256 b) { return
_mm256_add_ps(a, b); }
void foo(__m256 a, const __m256 b) { a = add(a, b); }
static inline __m128 add(const __m128 a, const __m128 b) { return
_mm_add_ps(a, b); }
void foo(__m128 a, const __m128 b) { a = add(a, b); }
compiled with -O2 -mavx
lead to
vmovups (%rdi), %xmm1
vinsertf128 $0x1, 16(%rdi), %ymm1, %ymm1
vaddps %ymm0, %ymm1, %ymm0
vmovaps %ymm0, (%rdi)
for the __m256 case and
vmovups (%rdi), %xmm1
vaddps %xmm0, %xmm1, %xmm0
vmovaps %xmm0, (%rdi)
for the __m128 case.
It should rather be:
vaddps (%rdi), %ymm0, %ymm0
vmovaps %ymm0, (%rdi)
and:
vaddps (%rdi), %xmm0, %xmm0
vmovaps %xmm0, (%rdi)
The latter result can be obtained if the const-ref arguments to add are changed
to pass by value.
[Bug c++/55418] Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55418 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-23 15:34:51 UTC --- Author: paolo Date: Fri Nov 23 15:34:45 2012 New Revision: 193758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193758 Log: 2012-11-23 Markus Trippelsdorf mar...@trippelsdorf.de PR c++/55418 * method.c (implicitly_declare_fn): Properly initialize trivial_p. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug c++/55418] Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55418 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 15:35:55 UTC --- Fixed.
[Bug c++/55449] New: [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449
Bug #: 55449
Summary: [4.4.3] pure virtual call only with -O1/2/3
(boost::optional)
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mend...@gmail.com
Created attachment 28765
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28765
test case + preprocessor output
The following code generates a pure virtual method call only when compiled with
-O1/O2/O3, the same code seems working without error with gcc 4.7.3.
The code is inlined in here and I have attached an archive containing the
preprocessor output as well.
Consider that it doesn't crash if:
- Remove the noncopyable from B
or
- Remove one of the two segments in the extra scope in main
or
- Remove the try { } catch
I have tried with boost 1.40, 1.50 and 1.52
#include boost/optional.hpp
#include boost/noncopyable.hpp
class B : boost::noncopyable { //if the noncopyable is removed works
public:
virtual size_t bar() const = 0;
};
class D : public B {
public:
D()
:theBar(foo(10))
{ }
virtual size_t bar() const {
return theBar;
}
private:
static size_t foo(const boost::optionalsize_t a) {
if (a) { //if this is a.is_initialized() then it works
return a.get();
}
return 2;
}
const size_t theBar;
};
class Foo {
public:
Foo(const B b)
:theBar(b.bar() * b.bar())
{ }
private:
const size_t theBar;
};
int main()
{
{ //if this section is removed works
D d;
try {
Foo myCompound(d);
} catch(...) {}
}
{
D d;
try {
Foo myCompound(d);
} catch(...) {}
}
}
[Bug rtl-optimization/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-23 16:00:35 UTC --- Author: ebotcazou Date: Fri Nov 23 16:00:26 2012 New Revision: 193760 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193760 Log: PR rtl-optimization/55388 * alias.c (nonoverlapping_component_refs_p): Handle bitfields. * emit-rtl.c (adjust_address_1): Deal with VOIDmode early. * expmed.c (store_bit_field): Turn the call to adjust_address into a call to adjust_bitfield_address_size. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/emit-rtl.c trunk/gcc/expmed.c
[Bug rtl-optimization/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-23 16:02:20 UTC --- Fix applied.
[Bug c++/54046] [4.6/4.7/4.8 Regression] wrong control reaches end of non-void function for switch case with throw and default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54046 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 16:04:14 UTC --- Author: jakub Date: Fri Nov 23 16:04:03 2012 New Revision: 193762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193762 Log: PR c++/54046 * Makefile.in (gimple-low.o): Depend on langhooks.h. * gimple-low.c: Include langhooks.c. (block_may_fallthru): Handle TARGET_EXPR and ERROR_MARK, by default call lang_hooks.block_may_fallthru. * langhooks.h (struct lang_hooks): Add block_may_fallthru langhook. * langhooks-def.h (LANG_HOOKS_BLOCK_MAY_FALLTHRU): Define. (LANG_HOOKS_INITIALIZER): Use it. * cp-objcp-common.h (LANG_HOOKS_BLOCK_MAY_FALLTHRU): Redefine. * cp-objcp-common.c (cxx_block_may_fallthru): New function. * cp-tree.h (cxx_block_may_fallthru): New prototype. * g++.dg/warn/Wreturn-type-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wreturn-type-8.C Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-objcp-common.h trunk/gcc/cp/cp-tree.h trunk/gcc/gimple-low.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 --- Comment #14 from Richard Perrin rcp at sentientmeat dot ca 2012-11-23 16:05:48 UTC --- gcc 4.5.4 does not suffer from the problem compiling the attached repro code, indicating this is a 4.6 regression.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-23 16:06:00 UTC --- GCC 4.4 is no longer supported, and the problem seems to be already fixed in current releases.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 16:10:47 UTC --- Closing then.
[Bug sanitizer/55435] [asan] implement an attribute to disable asan instrumentation for a particular function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55435 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 16:50:55 UTC --- Fixed.
[Bug other/55450] New: libtool: install: error: cannot install `libtsan.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55450 Bug #: 55450 Summary: libtool: install: error: cannot install `libtsan.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de This issue was fixed by H.J. a few days ago, but it reappeared today: make[4]: Entering directory `/var/tmp/gcc_build_dir/x86_64-pc-linux-gnu/libsanitizer/tsan' test -z /usr/lib/gcc/x86_64-pc-linux-gnu/ || /bin/mkdir -p /usr/lib/gcc/x86_64-pc-linux-gnu/ /bin/sh ../libtool --mode=install /usr/bin/install -c libtsan.la '/usr/lib/gcc/x86_64-pc-linux-gnu/' libtool: install: error: cannot install `libtsan.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/ make[4]: *** [install-toolexeclibLTLIBRARIES] Error 1 Configured with: ~/gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-build-config=slim-lto-bootstrap --with-boot-ldflags=-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3 --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes
[Bug target/55448] using const-reference SSE or AVX types leads to unnecessary unaligned loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-23 CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 17:28:01 UTC --- The low alignment originates from eipa_sra, foo isn't still in SSA form, and ipa_modify_call_arguments computes align and misalign of base, which is PARM_DECL (of REFERENCE_TYPE, referencing __m256 with 256-bit alignment). But get_pointer_alignment_1 for PARM_DECLs always returns 8-bit alignment.
[Bug regression/55451] New: FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 Bug #: 55451 Summary: FAIL: gcc.dg/fixed-point/unary.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: gre...@gcc.gnu.org CC: ja...@gcc.gnu.org Target: arm-none-eabi FAIL: gcc.dg/fixed-point/unary.c execution test /work/nov-builds/strcmp/arm-none-eabi/gcc2/gcc/xgcc -B/work/nov-builds/strcmp/arm-none-eabi/gcc2/gcc/ /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/fixed-point/unary.c gcc_tg.o -fno-diagnostics-show-caret -std=gnu99 -DSTACK_SIZE=16384 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./unary.exe(timeout = 60) PASS: gcc.dg/fixed-point/unary.c (test for excess errors) *** EXIT code 4242 FAIL: gcc.dg/fixed-point/unary.c execution test Execution fails on line 197 gcc.dg/fixed-point/unary.c, when executing the test FRACT_SAT_NEG(_Sat long _Fract, lr); The problem is actually in one of the files gcc automatically generates. Caused by r193028. Author cced on this report. Reduced test attached. ./cc1 -fpreprocessed /work/bisect/_ssnegSQ.i -quiet -dumpbase _ssnegSQ.i -mcpu=cortex-a15 -mfloat-abi=softfp -mfpu=neon-vfpv4 -auxbase-strip _ssnegSQ.o -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc -fno-stack-protector -fno-inline -fvisibility=hidden -o ssneg.s -O1 -da -dp -fdump-tree-all diff good/_ssnegSQ.i.081t.reassoc1 bad/_ssnegSQ.i.081t.reassoc1 23c23 if (_2 0) --- if (1 == 1) 29c29 if (z_3 0) --- if (0 != 0)
[Bug regression/55451] FAIL: gcc.dg/fixed-point/unary.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55451 --- Comment #1 from gretay at gcc dot gnu.org 2012-11-23 17:41:44 UTC --- Created attachment 28766 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28766 reduced preprocessed input that causes the failure
[Bug target/55448] using const-reference SSE or AVX types leads to unnecessary unaligned loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
Target Milestone|--- |4.8.0
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23
17:50:56 UTC ---
With -O2 -mavx -fno-ipa-sra the whole
#include x86intrin.h
static inline __m256
add1 (const __m256 a, const __m256 b)
{
return _mm256_add_ps (a, b);
}
void
f1 (__m256 a, const __m256 b)
{
a = add1 (a, b);
}
static inline __m128
add2 (const __m128 a, const __m128 b)
{
return _mm_add_ps (a, b);
}
void
f2 (__m128 a, const __m128 b)
{
a = add2 (a, b);
}
static inline __m256
add3 (const __m256 *a, const __m256 *b)
{
return _mm256_add_ps (*a, *b);
}
void
f3 (__m256 *a, const __m256 b)
{
*a = add3 (a, b);
}
static inline __m128
add4 (const __m128 *a, const __m128 *b)
{
return _mm_add_ps (*a, *b);
}
void
f4 (__m128 *a, const __m128 b)
{
*a = add4 (a, b);
}
testcase compiles into optimal code. Beyond the eipa_sra issue the thing is
that for AVX/AVX2 we generally should attempt to combine unaligned loads with
operations that use them (unless it is a plain move), but there is UNSPEC_LOADU
involved (and for 256-bit values also vec_concat with another MEM load), so not
sure what would be the best pass to handle that, if some hack in the combiner,
peephole2 (but we'd need many of them) or what.
[Bug tree-optimization/55415] Early SRA produces unaligned complex types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55415 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-23 18:01:56 UTC --- Possibly related to PR55448.
[Bug testsuite/55452] New: [4.8 Regression]: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55452 Bug #: 55452 Summary: [4.8 Regression]: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: hubi...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 193563:193575 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ... ... FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 [0-9] \\* 22 The message in gfortran.log is: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gfortran/../../gfortran -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gfortran/../../ -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgfortran/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/reassoc_4.f -fno-diagnostics-show-caret -O -O3 -ffast-math -fdump-tree-reassoc1 -S -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -o reassoc_4.s (timeout = 300) PASS: gfortran.dg/reassoc_4.f -O (test for excess errors) FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 [0-9] \\* 22 From looking at gcc-testresults archives, the regression is universal. Author of most suspect patch (r193570) in revision range CC:ed. It looks like just a testsuite adjustment missing.
[Bug fortran/55352] [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 --- Comment #9 from janus at gcc dot gnu.org 2012-11-23 19:05:20 UTC --- Author: janus Date: Fri Nov 23 19:05:14 2012 New Revision: 193766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193766 Log: 2012-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/55352 * trans-decl.c (generate_local_decl): Don't warn for explicitly imported but unused module variables which are in a namelist or common block. 2012-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/55352 * gfortran.dg/namelist_76.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/namelist_76.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-decl.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/55352] [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from janus at gcc dot gnu.org 2012-11-23 19:10:07 UTC --- The patch in comment 3 has been applied to trunk and the 4.7 branch, which means the bug will be fixed in the 4.7.3 and 4.8.0 releases. Closing as fixed. Thanks for the bugreport!
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2012-11-23 20:32:35 UTC --- I still got the same failure as in comment #13 with revision 193763.
[Bug c++/55453] New: Bug with virtual methods and objects with dtors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55453
Bug #: 55453
Summary: Bug with virtual methods and objects with dtors.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blitzmun...@gmail.com
Hi,
Mingw G++ appears to have a bug involving multiple inheritance and virtual
methods that return objects with dtors.
I have tried on 3 ditros - nuwen, tdm and the official mingw distro - and it
happens on all g++ versions = 4.7.0.
It does not appear to occur on Linux, although I've only been able to test with
kubuntu12 and mint14, both of which have g++ 4.7.2 installed.
Even though this appears to be mingw specific, I've already posted this bug
report on the mingw bug reports system and they told me to post it here.
Anyway, see below code: The problem occurs when the 'interface method'
LinkResolver is called by the markdown object. The correct method is invoked,
but the 'this' pointer is messed up.
The trigger seems to be the String dtor. Remove this, or have the interface
method return a simple type, and it works as expected.
Bye!
Mark
//* CODE **
#include stdio.h
struct String {
~String() { }
};
struct Object {
virtual ~Object() { }
};
struct LinkResolver {
virtual String ResolveLink() = 0;
};
struct Docs : public Object, public virtual LinkResolver {
Docs() {
printf( Docs::Docs() this: %p\n, this);
}
virtual String ResolveLink() {
printf(Docs::ResolveLink() this: %p\n, this);
return String();
}
};
struct Markdown {
LinkResolver * _resolver;
Markdown(LinkResolver * resolver) : _resolver(resolver) { }
void Go() {
_resolver-ResolveLink();
}
};
int main() {
printf(GCC %d.%d.%d\n, __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
Docs d;
printf( main() d: %p\n, d);
d.ResolveLink();
Markdown m(d);
m.Go();
}
[Bug target/55454] New: [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454
Bug #: 55454
Summary: [PPC] unaligned memory accesses do not work correctly
for vector extensions when using altivec
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com
The following test program reproduces the problem:
/***/
#include stdint.h
#include assert.h
typedef uint8_t uint8x16 __attribute__ ((vector_size(16)));
typedef struct { char dummy; uint8x16 data; } __attribute__((packed)) foo;
char __attribute__((aligned(16))) buffer[32];
void __attribute__((noinline)) init_buffer(const uint8x16 *a)
{
((foo *)(buffer + 9))-data = *a;
}
int main (void)
{
const uint8x16 a = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 };
assert(sizeof(foo) == 17);
init_buffer(a);
assert(buffer[0] == 0);
return 0;
}
/***/
$ gcc -O2 -maltivec -o test test.c
$ ./test
test: test.c:19: main: Assertion `buffer[0] == 0' failed.
Aborted
[Bug other/55450] libtool: install: error: cannot install `libtsan.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55450 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-23 21:14:09 UTC --- Author: hjl Date: Fri Nov 23 21:14:05 2012 New Revision: 193767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193767 Log: Set gcc_version in tsan/Makefile.am PR sanitizer/55450 * tsan/Makefile.am (gcc_version): New. * tsan/Makefile.in: Regenerated. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/tsan/Makefile.am trunk/libsanitizer/tsan/Makefile.in
[Bug sanitizer/55450] libtool: install: error: cannot install `libtsan.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55450 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|other |sanitizer Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-11-23 21:16:27 UTC --- Fixed.
[Bug c++/55453] Bug with virtual methods and objects with dtors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55453 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 21:44:57 UTC --- target/55171 ? (and we may already have yet another related issue)
[Bug c++/55453] Bug with virtual methods and objects with dtors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55453 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 21:51:10 UTC --- Yes, c++/55367. Kai, could you please double check this? *** This bug has been marked as a duplicate of bug 55367 ***
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||blitzmunter at gmail dot ||com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 21:51:10 UTC --- *** Bug 55453 has been marked as a duplicate of this bug. ***
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 21:57:11 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55171 ***
[Bug target/55171] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||wriabi at email dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 21:57:11 UTC --- *** Bug 55367 has been marked as a duplicate of this bug. ***
[Bug libstdc++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-23 22:11:30 UTC --- Author: redi Date: Fri Nov 23 22:11:23 2012 New Revision: 193769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193769 Log: PR libstdc++/52680 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Check for usleep and sleep if nanosleep is not available. Bump libtool revision. * config.h.in: Regenerate. * configure: Likewise. * config/abi/pre/gnu.ver (GLIBCXX_3.4.18): Add __sleep_for. * include/std/thread (this_thread::__sleep_for): Add. (this_thread::yield, this_thread::sleep_until, this_thread::sleep_for): Declare unconditionally. * src/c++11/thread.cc (this_thread::__sleep_for): Define. * testsuite/lib/libstdc++.exp (check_v3_target_nanosleep): Rename to check_v3_target_sleep. * testsuite/lib/dg-options.exp (dg-require-nanosleep): Rename to dg-require-sleep. * testsuite/30_threads/condition_variable_any/53830.cc: Update. * testsuite/30_threads/this_thread/2.cc: Likewise. * testsuite/30_threads/this_thread/3.cc: Likewise. * testsuite/30_threads/this_thread/4.cc: Likewise. * testsuite/30_threads/async/54297.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/include/std/thread trunk/libstdc++-v3/src/c++11/thread.cc trunk/libstdc++-v3/testsuite/30_threads/async/54297.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/53830.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/2.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/3.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/4.cc trunk/libstdc++-v3/testsuite/lib/dg-options.exp trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
[Bug c++/55446] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-23 22:21:30 UTC --- I observe the same thing with gcc 4.8.0 20121104 (experimental) on my mingw-x86_64 system. Odd.
[Bug c++/55446] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-23 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-23 22:28:26 UTC --- Yes, this is confirmed.
[Bug c++/55446] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|major |normal
[Bug libstdc++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-23 22:31:14 UTC --- fixed for 4.8, this_thread::sleep_for is always defined
[Bug sanitizer/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-11-23 23:11:21 UTC --- The reason for relink_command is that libsanitizer depends on libstdc++.la. make install DESTDIR==foobar works for me.
[Bug bootstrap/55455] New: [4.8 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55455 Bug #: 55455 Summary: [4.8 Regression] Failed to bootstrap Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/i686, revision 193770 gave: ../../../src-trunk/libquadmath/printf/printf_fphex.c:28:36: fatal error: quadmath-rounding-mode.h: No such file or directory #include quadmath-rounding-mode.h ^ compilation terminated.
[Bug c++/55446] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||wrong-code --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 00:30:40 UTC --- build_new_1, called by build_new, returns error_mark_node. This happens because something goes very badly wrong in the cp_build_binary_op call around line 2712: essentially it computes 0 - 1!
[Bug middle-end/55456] New: [4.8 Regression] 454.calculix in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55456 Bug #: 55456 Summary: [4.8 Regression] 454.calculix in SPEC CPU 2006 is miscompiled Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com On Linux/i686, revision 193723 miscompiled 454.calculix in SPEC CPU 2006 with -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -ffixed-form 454.calculix is compiled into an infinite loop.
[Bug bootstrap/55455] [4.8 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55455 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-24 01:13:07 UTC --- Author: hjl Date: Sat Nov 24 01:12:59 2012 New Revision: 193775 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193775 Log: Don't pass void to fegetround PR bootstrap/55455 * quadmath-rounding-mode.h (get_rounding_mode): Don't pass void to fegetround. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/quadmath-rounding-mode.h
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.7.3 Summary|array new with size zero|[4.7/4.8 Regression] array |vanishes from object code |new with size zero vanishes ||from object code --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 01:24:38 UTC --- And it's a regression.
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 01:52:49 UTC --- And it's mine because I caused it with the fix for PR45385 :(
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com
[Bug bootstrap/55455] [4.8 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55455 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-11-24 02:02:55 UTC --- Fixed.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #3 from Gaetano Mendola mendola at gmail dot com 2012-11-24 06:27:06 UTC --- Time to adopt ICC.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-24 06:37:08 UTC --- (In reply to comment #3) Time to adopt ICC. There is only so much resources to support older versions of GCC. If you want support for older versions of GCC, then you should pay someone (like you do for ICC).
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #5 from Gaetano Mendola mendola at gmail dot com 2012-11-24 06:57:16 UTC --- I have no problem to pay someone, I'm a bit disappointed seeing a bug closed because new version works without investigate if the problem is still there in new versions but not triggered by my test case. Also if 4.4.3 is not supported why while submitting the bug I was able to target the 4.4.3?
[Bug middle-end/55456] [4.8 Regression] 454.calculix in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55456 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||vmakarov at redhat dot com Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-24 06:58:38 UTC --- It is caused by revision 193310: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00257.html
