[Bug c++/107128] armhf: floatn-common.h:214:9: error: multiple types in one declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128 --- Comment #7 from Mike Hommey --- Forget my last comment, it came from the use of a sysroot with an older glibc. I wonder why the sysroot path didn't appear in those messages...
[Bug c++/107128] armhf: floatn-common.h:214:9: error: multiple types in one declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128 Mike Hommey changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #6 from Mike Hommey --- I'm getting a similar error on x86-64 Debian 11 with libc6 2.31: In file included from /usr/include/wchar.h:30, from /builds/worker/fetches/gcc-objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cwchar:44, from /builds/worker/fetches/gcc-objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h:40, from /builds/worker/fetches/gcc-objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/iosfwd:42, from /builds/worker/fetches/gcc-objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr.h:52, from /builds/worker/fetches/gcc-objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/memory:80, from ../../gcc-source/libcody/cody.hh:24, from ../../gcc-source/libcody/internal.hh:5, from ../../gcc-source/libcody/packet.cc:6: /usr/include/x86_64-linux-gnu/bits/floatn.h:87:9: error: multiple types in one declaration 87 | typedef __float128 _Float128; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn.h:87:20: error: declaration does not declare anything [-fpermissive] 87 | typedef __float128 _Float128; |^ In file included from /usr/include/x86_64-linux-gnu/bits/floatn.h:120: /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:9: error: multiple types in one declaration 214 | typedef float _Float32; | ^ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive] 214 | typedef float _Float32; | ^~~~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:9: error: multiple types in one declaration 251 | typedef double _Float64; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive] 251 | typedef double _Float64; |^~~~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:9: error: multiple types in one declaration 268 | typedef double _Float32x; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:16: error: declaration does not declare anything [-fpermissive] 268 | typedef double _Float32x; |^ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:14: error: multiple types in one declaration 285 | typedef long double _Float64x; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:21: error: declaration does not declare anything [-fpermissive] 285 | typedef long double _Float64x; | ^
[Bug other/107694] New: Bogus stringop-overflow warning in gcc 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107694
Bug ID: 107694
Summary: Bogus stringop-overflow warning in gcc 12
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Reproducer:
```
#include
class nsISupports {
public:
virtual int Release();
};
struct JSPrincipals {
std::atomic refcount;
};
class nsJSPrincipals : nsISupports, JSPrincipals {
static nsJSPrincipals* get(JSPrincipals* principals) {
return static_cast(principals);
}
void Destroy(JSPrincipals* jsprin);
};
void nsJSPrincipals::Destroy(JSPrincipals* jsprin) {
nsJSPrincipals* nsjsprin = nsJSPrincipals::get(jsprin);
nsjsprin->refcount.fetch_add(1, std::memory_order_acq_rel);
nsjsprin->Release();
}
```
Compile with: g++ -c -O2 -Werror=stringop-overflow
It says:
```
In file included from /builds/worker/fetches/gcc/include/c++/12.2.0/atomic:41,
from Unified_cpp_caps0.ii.cpp:1:
In member function 'std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::fetch_add(__int_type, std::memory_order) [with _ITp
= int]',
inlined from 'void nsJSPrincipals::Destroy(JSPrincipals*)' at
Unified_cpp_caps0.ii.cpp:19:30:
/builds/worker/fetches/gcc/include/c++/12.2.0/bits/atomic_base.h:618:34: error:
'unsigned int __atomic_fetch_add_4(volatile void*, unsigned int, int)' writing
4 bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
618 | { return __atomic_fetch_add(&_M_i, __i, int(__m)); }
|~~^~
cc1plus: some warnings being treated as errors
```
[Bug c++/106633] Hidden visibility on forward declarations impacts visibility of default-visibility class methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633 Mike Hommey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Mike Hommey --- Started with https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a53781c8fd258608780821168a7f5faf7be63690;hp=ba9b07d0259b38a9eccd4eb0df327d3aaabad3c6 ... which points to the fact that this is now consistent with the behavior of forward declarations of any other class...
[Bug c++/106633] New: Hidden visibility on forward declarations impacts visibility of default-visibility class methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633
Bug ID: 106633
Summary: Hidden visibility on forward declarations impacts
visibility of default-visibility class methods
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
This was not happening before GCC 12.
Reduced testcase from a Firefox build failure we got in Debian on armhf:
```
#pragma GCC visibility push(hidden)
namespace std { class type_info; }
#pragma GCC visibility pop
#include
bool foo(std::type_info& a, std::type_info& b) { return a == b; }
```
Compile with `-O2 -D__GXX_TYPEINFO_EQUALITY_INLINE=0` (the define makes the
problem appear on all platforms, rather than armhf only)
What happens in this example is that the symbol reference to
`std::type_info::operator==` ends up with hidden visibility, instead of default
visibility. With GCC 11 and older versions, it would end up with default
visibility.
On godbolt:
https://godbolt.org/z/hYKjWGaeq
(Ironically(?), that forward declaration comes from ICU working around an old
bug in libstdc++ headers)
[Bug c++/104142] [9/10/11 Regression] Spurious warning unused-variable on const static variable and defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142 --- Comment #7 from Mike Hommey --- (In reply to Mike Hommey from comment #6) > There's a different warning that interestingly only happens on 11.2 and 11.3 > (not 11.1 or earlier versions), that is fixed by the patch in this bug: Forgot to mention: that warning was a regression from bug 101029
[Bug c++/104142] [9/10/11 Regression] Spurious warning unused-variable on const static variable and defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #6 from Mike Hommey ---
There's a different warning that interestingly only happens on 11.2 and 11.3
(not 11.1 or earlier versions), that is fixed by the patch in this bug:
```
struct Foo {
explicit constexpr Foo(char) {}
};
const Foo foo[] = {};
```
```
: In function 'void __static_initialization_and_destruction_0(int,
int)':
:5:11: error: statement has no effect [-Werror=unused-value]
5 | const Foo foo[] = {};
| ^~~
```
[Bug c++/100666] New: warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; typename std::remove_reference<_Tp>::type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666
Bug ID: 100666
Summary: warning: ignoring return value of 'constexpr _Tp&&
std::forward(typename
std::remove_reference<_Tp>::type&) [with _Tp =
std::nullptr_t; typename
std::remove_reference<_Tp>::type = std::nullptr_t]',
declared with attribute 'nodiscard' [-Wunused-result]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
(Note I'm not entirely sure this is a GCC bug, but it doesn't happen with GCC <
11 and with clang)
Reduced testcase:
```
#include
extern void foo(...);
template
void bar(Ts&&... aArgs) {
foo(std::forward(aArgs)...);
}
void qux() {
bar(nullptr);
}
```
This emits the following warning:
```
: In instantiation of 'void bar(Ts&& ...) [with Ts =
{std::nullptr_t}]':
:11:8: required from here
:7:25: warning: ignoring return value of 'constexpr _Tp&&
std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp =
std::nullptr_t; typename std::remove_reference<_Tp>::type = std::nullptr_t]',
declared with attribute 'nodiscard' [-Wunused-result]
7 | foo(std::forward(aArgs)...);
| ^~~
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:59,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/move.h:77:5: note:
declared here
77 | forward(typename std::remove_reference<_Tp>::type& __t) noexcept
| ^~~
```
(https://godbolt.org/z/GW3xf71n3)
Incidentally, using the x86-64 gcc (static analysis) on compiler explorer fails
with:
```
during IPA pass: analyzer
: In function 'void qux()':
:11:9: internal compiler error: in make_region_for_type, at
analyzer/region-model.cc:5973
11 | bar(nullptr);
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
```
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #7 from Mike Hommey --- It's worth noting that the clang variant of the code makes use of __builtin_shufflevector, which the gcc variant doesn't (per https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/vector_type.h), so the build time comparison might be influenced by that. clang does manage to inline blend_pixels, though, and the resulting code is much smaller than what GCC produces.
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #6 from Mike Hommey --- Replacing __attribute__((always_inline)) with inline on the two blend_pixels functions makes it go down to 30s with GCC 10. See https://bugzilla.mozilla.org/show_bug.cgi?id=1700520#c9 why the functions were marked always_inline in the first place.
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #4 from Mike Hommey --- GCC 11 is the package in Debian experimental, so however it's built.
[Bug c++/99785] New: Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 Bug ID: 99785 Summary: Awful lot of time spent building gl.cc in Firefox Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org Target Milestone: --- Created attachment 50475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50475=edit gl.ii.gz Compiling the attached preprocessed source takes 27 minutes with GCC 10 with `g++ -o gl.o -c gl.ii -O2 -std=gnu++17 -g -pipe` and a grand total of 21GB of memory spread between cc1plus (15G) and gas (6GB). It's also slow to process at -O0. This goes up to 4 hours (!) with GCC 11 and less than 1 minute with clang.
[Bug c/99784] `labels as values`can point to the wrong spot after optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99784 --- Comment #3 from Mike Hommey --- PR 96956 only really talks about this: "You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things happen.". My testcase doesn't involve jumping to the address.
[Bug c/99784] `labels as values`can point to the wrong spot after optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99784 --- Comment #1 from Mike Hommey --- This is reproducible with all versions of GCC on godbolt, including trunk.
[Bug c/99784] New: `labels as values`can point to the wrong spot after optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99784
Bug ID: 99784
Summary: `labels as values`can point to the wrong spot after
optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Reduced testcase:
```
extern void bar();
extern void qux(void*);
void foo() {
bar();
here:
qux(&);
}
```
Resulting code at -O2:
```
foo():
.LFB0:
.L2:
sub rsp, 8
callbar()
.LVL0:
mov edi, OFFSET FLAT:.L2
add rsp, 8
jmp qux(void*)
```
IOW, the pointer that qux gets is that of a location before the call to bar!
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #22 from Mike Hommey --- For the record, this also affects ppc64.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #20 from Mike Hommey --- Note this also affects mips and presumably mips64 (except for the latter, the code has a ifdef that disables inlining presumably because of this ICE)
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #19 from Mike Hommey --- Applying the patch from PR90139 and this one works fixes the ICEs on this file with both GCC 7 and 8.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #18 from Mike Hommey --- And similar ICE as comment 14 with 8.3 too. 9.1 works with the patch.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #17 from Mike Hommey --- (In reply to Mike Hommey from comment #16) > Similar ICE with 7.3. And 7.4 (and to be clear, this is similar ICE as comment 14)
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #16 from Mike Hommey --- Similar ICE with 7.3.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #14 from Mike Hommey --- If I apply the patch on 6.4, I'm getting a different ICE: internal compiler error: in emit_block_move_hints, at expr.c:1099 [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - static void exec_ops(const Op* ops, const void** args, [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - ^~~~ [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - 0x8d20b5 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/expr.c:1099 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0x8d210f emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods) [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/expr.c:1158 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 emit_partition_copy [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:220 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 insert_part_to_rtx_on_edge [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:388 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 elim_create [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:702 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 eliminate_phi [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:760 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 expand_phi_nodes(ssaexpand*) [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:937 [task 2019-07-04T09:48:09.109Z] 09:48:09 INFO - 0x7fedb9 execute [task 2019-07-04T09:48:09.109Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/cfgexpand.c:6317
[Bug rtl-optimization/90756] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #4 from Mike Hommey --- Also note it does *not* happen on i686 when SSE is enabled.
[Bug rtl-optimization/90756] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #3 from Mike Hommey ---
This also happens on mips and mipsel. Here's a further reduced version,
courtesy of creduce:
typedef enum { a, c } d;
template struct g {
typedef f __attribute__((vector_size(e * sizeof(int h;
};
template using i = typename g::h;
using j = i<4, float>;
using k = i<4, short>;
template void cast(l);
d m;
void n() {
j o, b;
while (true)
switch (m) {
case a: {
j p = o;
o = b;
b = p;
}
case c:
cast(b);
}
}
[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560 --- Comment #14 from Mike Hommey <mh+gcc at glandium dot org> --- (In reply to Andreas Schwab from comment #13) > alignof(long long) "type of a complete object" > alignof(foo) "type of a subobject" But that doesn't tell why the alignment of a long long is 8 as a complete object, but 4 as a subobject (the offset of l in foo is 4, not 8).
[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Mike Hommey <mh+gcc at glandium dot org> changed:
What|Removed |Added
CC| |mh+gcc at glandium dot org
--- Comment #12 from Mike Hommey <mh+gcc at glandium dot org> ---
(In reply to Jonathan Wakely from comment #11)
> > See Joseph's explanation at:
> > https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00435.html
>
> Which refers to 3.11 [basic.align] p2:
>
>The alignment required for a type might be different when it is used as
> the
>type of a complete object and when it is used as the type of a subobject.
That doesn't seem to explain why the following is not true when compiling with
-m32:
struct foo {
char c;
long long l;
};
static_assert(alignof(long long) == alignof(foo), "");
[Bug ipa/70559] Miscompilation of nsTextFormatter.cpp from Firefox with -Os -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70559 --- Comment #2 from Mike Hommey <mh+gcc at glandium dot org> --- Created attachment 38198 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38198=edit nsTextFormatter.ii Err, sorry.
[Bug ipa/70559] New: Miscompilation of nsTextFormatter.cpp from Firefox with -Os -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70559
Bug ID: 70559
Summary: Miscompilation of nsTextFormatter.cpp from Firefox
with -Os -fomit-frame-pointer
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
We've recently switched to GCC 4.8 to build Firefox (yeah, I know...), and
valgrind detected an error that we subsequently identified as what looks like a
GCC codegen/ipa bug. I was able to reproduce with GCC 4.9.3 from Debian
(4.9.3-12) on x86-64. It doesn't reproduce with GCC 5, however.
Command line to reproduce:
$ g++ -std=gnu++11 -g -Os -fomit-frame-pointer -fno-exceptions
nsTextFormatter.ii -S -o nsTextFormatter.s
Look at the resulting assembly, and look at what corresponds to
nsTextFormatter.cpp:857 (search for ".loc 1 857). It looks like the following:
.loc 1 857 0
movl0(%rbp), %eax
leaq2(%rbp), %r12
.LVL184:
testw %ax, %ax
je .L526
The corresponding C++ is:
while ((c = *aFmt++) != 0) {
where c is a char16_t and aFmt a const char16_t*.
Note how it's using movl to read *aFmt, instead of movw. Which means it can
read 2 bytes past the end of aFmt (and it does, that's what valgrind complains
about, and it does so while reading at a 2-aligned address, so it's not about
the read being considered safe because always 4-aligned, although it might be a
misevaluation of that).
Building with -fno-omit-frame-pointer, the assembly looks like:
.loc 1 857 0
movw(%r12), %ax
leaq2(%r12), %r13
.LVL183:
testw %ax, %ax
je .L525
[Bug ipa/65765] [5/6 Regression] Compiling Firefox with GCC 5 leads to broken javascript engine on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65765 --- Comment #5 from Mike Hommey mh+gcc at glandium dot org --- I can confirm that building Firefox with -fno-ipa-icf fixes the issue as well (that is, that the testcase is correctly related to the Firefox breakage)
[Bug gcov-profile/65761] internal compiler error: in patch_jump_insn, at cfgrtl.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761 --- Comment #3 from Mike Hommey mh+gcc at glandium dot org --- Created attachment 35309 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35309action=edit Unified_cpp_js_src5.i The full compile command line is: g++ -m32 -march=pentiumpro -o Unified_cpp_js_src5.o -c -I../../dist/system_wrappers -include /builds/slave/try-lx-000/build/src/config/gcc_hidden.h -DFFI_BUILDING -DENABLE_BINARYDATA -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX='lib' -DDLL_SUFFIX='.so' -DMOZ_GLUE_IN_PROGRAM -DAB_CD= -DNO_NSPR_10_SUPPORT -I/builds/slave/try-lx-000/build/src/js/src -I. -Ictypes/libffi/include -I/builds/slave/try-lx-000/build/src/intl/icu/source/common -I/builds/slave/try-lx-000/build/src/intl/icu/source/i18n -I../../dist/include -I/builds/slave/try-lx-000/build/src/obj-firefox/dist/include/nspr -fPIC -DMOZILLA_CLIENT -include ../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src5.o.pp -Wall -Wsign-compare -Wtype-limits -Werror=char-subscripts -Werror=comment -Werror=endif-labels -Werror=ignored-qualifiers -Werror=int-to-pointer-cast -Werror=missing-braces -Werror=overloaded-virtual -Werror=parentheses -Werror=pointer-arith -Werror=reorder -Werror=return-type -Werror=sequence-point -Werror=switch -Werror=trigraphs -Werror=unknown-pragmas -Werror=unused-label -Werror=unused-value -Werror=write-strings -Werror=conversion-null -Wno-invalid-offsetof -Wcast-align -Wno-error=uninitialized -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fno-omit-frame-pointer -Werror /builds/slave/try-lx-000/build/src/obj-firefox/js/src/Unified_cpp_js_src5.cpp ... and it doesn't happen without the profile data. I'm trying to get that.
[Bug gcov-profile/65761] New: internal compiler error: in patch_jump_insn, at cfgrtl.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761 Bug ID: 65761 Summary: internal compiler error: in patch_jump_insn, at cfgrtl.c:1296 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org This happened while building Firefox with PGO with GCC 5.1.0-RC-20150412, compiled with --enable-languages=c,c++ --disable-nls --disable-gnu-unique-object --enable-__cxa_atexit --with-arch-32=pentiumpro. As it happened on Mozilla automation, though, I don't have more than the build logs, unfortunately. This happened building a x86 (32-bits) Firefox on a x86-64 host with a x86-64 toolchain. 00:57:02 INFO - In file included from /builds/slave/try-lx-000/build/src/obj-firefox/js/src/Unified_cpp_js_src5.cpp:92:0: 00:57:02 INFO - /builds/slave/try-lx-000/build/src/js/src/jit/RangeAnalysis.cpp: In member function 'bool js::jit::RangeAnalysis::addBetaNodes()': 00:57:02 INFO - /builds/slave/try-lx-000/build/src/js/src/jit/RangeAnalysis.cpp:294:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1296 00:57:02 INFO - } 00:57:02 INFO - ^ 00:57:02 INFO - 0x7c6943 patch_jump_insn 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:1296 00:57:02 INFO - 0x7c6d6b redirect_branch_edge 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:1329 00:57:02 INFO - 0x7c72f2 rtl_redirect_edge_and_branch 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:1462 00:57:02 INFO - 0x7b94c9 redirect_edge_and_branch(edge_def*, basic_block_def*) 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfghooks.c:376 00:57:02 INFO - 0x7c6b8a rtl_split_edge 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:1960 00:57:02 INFO - 0x7b9acb split_edge(edge_def*) 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfghooks.c:635 00:57:02 INFO - 0x7c8304 commit_one_edge_insertion(edge_def*) 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:2075 00:57:02 INFO - 0x7c8569 commit_edge_insertions() 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/cfgrtl.c:2142 00:57:02 INFO - 0xa51380 convert_regs 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/reg-stack.c:3175 00:57:02 INFO - 0xa51380 reg_to_stack 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/reg-stack.c:3283 00:57:02 INFO - 0xa51380 rest_of_handle_stack_regs 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/reg-stack.c:3338 00:57:02 INFO - 0xa51380 execute 00:57:02 INFO - ../../gcc-5.1.0-RC-20150412/gcc/reg-stack.c:3369 Please tell me if you need the input files or if the backtrace is enough.
[Bug gcov-profile/65761] internal compiler error: in patch_jump_insn, at cfgrtl.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761 --- Comment #4 from Mike Hommey mh+gcc at glandium dot org --- Created attachment 35310 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35310action=edit Unified_cpp_js_src5.gcda
[Bug gcov-profile/65761] internal compiler error: in patch_jump_insn, at cfgrtl.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761 --- Comment #5 from Mike Hommey mh+gcc at glandium dot org --- I can reproduce with: g++ -m32 -march=pentiumpro -o Unified_cpp_js_src5.o -c -fPIC -Wno-invalid-offsetof -fno-exceptions -std=gnu++0x -fprofile-use -fprofile-correction -O3 -fno-omit-frame-pointer Unified_cpp_js_src5.i It doesn't happen when removing -fno-omit-frame-pointer.
[Bug gcov-profile/65761] internal compiler error: in patch_jump_insn, at cfgrtl.c:1296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761 --- Comment #6 from Mike Hommey mh+gcc at glandium dot org --- It also doesn't happen at -O2.
[Bug ipa/65765] Compiling Firefox with GCC 5 leads to broken javascript engine on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65765 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org --- git bisect identified this commit as the first one where the reduced testcase fails: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=52200d03c231f0bddbd4bbc5cd3608c6a1dd4598 svn+ssh://gcc.gnu.org/svn/gcc/trunk@216305
[Bug ipa/65765] New: Compiling Firefox with GCC 5 leads to broken javascript engine on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65765 Bug ID: 65765 Summary: Compiling Firefox with GCC 5 leads to broken javascript engine on x86-64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org Created attachment 35314 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35314action=edit reduced.tgz When building Firefox with GCC 5 [1], some parts of the test suite fail because of what might be a compiler bug. It seems to be involving __attribute__((cold)). Dan Gohman got a reduced testcase, attached here. Unpack and build with g++ -O2 *.cpp, then run a.out. This doesn't happen at -O1, or with -O2 -Dcold=. 1. GCC 5.1.0-RC-20150412, compiled with --enable-languages=c,c++ --disable-nls --disable-gnu-unique-object --enable-__cxa_atexit --with-arch-32=pentiumpro. I've also reproduced with the reduced testcase with a snapshot of 5-20150111 (building Firefox with that snapshot fails for other reasons, unfortunately).
[Bug target/61208] armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 --- Comment #2 from Mike Hommey mh+gcc at glandium dot org --- This doesn't happen with gcc 4.9.
[Bug target/61208] New: armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 Bug ID: 61208 Summary: armhf: generated asm code produces branch out of range error in gas with -Os Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org Created attachment 32811 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32811action=edit Preprocessed source (compressed) On Debian unstable, with debian gcc 4.8.2-21, the attached preprocessed source fails to build with: /tmp/cc9VIAtd.s: Assembler messages: /tmp/cc9VIAtd.s:827: Error: branch out of range
[Bug target/61208] armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org --- Created attachment 32812 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32812action=edit Corresponding assembly (compressed) This is the assembly I got with the full normal command line. But I can reproduce with the following command line: g++ -o CertVerifier.o -c CertVerifier.ii -Os -std=gnu++0x The problematic line is a cbz call, and i guess the label ends up at more than 130 bytes from the call.
[Bug gcov-profile/59973] New: Creates a 32GB unused bss symbol with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973 Bug ID: 59973 Summary: Creates a 32GB unused bss symbol with -fprofile-generate Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org $ g++-4.7 -o - -S Value.ii -std=gnu++0x -O1 -fprofile-generate (snip) .quad.LPBX1 .local.LPBX1 .comm.LPBX1,34359738368,64 $ g++-4.7 -o Value.o -c Value.ii -std=gnu++0x -O1 -fprofile-generate $ readelf -SW /tmp/Value.o | grep bss [ 5] .bss NOBITS 000100 8 00 WA 0 0 64 Note this doesn't happen with gcc 4.8. This happens with current 4.7.3 from Debian (4.7.3-10 as of writing) and a locally built vanilla gcc 4.7.3. Further down the road, this makes code fail to link because the linker can't do R_X86_64_PC32 relocations across the 32GB gap (text relocations for acesses to bss symbols that happen to be after that one).
[Bug gcov-profile/59973] Creates a 32GB unused bss symbol with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org --- Created attachment 31971 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31971action=edit Value.ii.gz Looks like the attachment didn't work at bug creation time.
[Bug gcov-profile/55650] [4.8 Regression] Firefox profiledbuild: libxul.so: cannot map zero-fill pages: Cannot allocate memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55650 --- Comment #4 from Mike Hommey mh+gcc at glandium dot org --- *** Bug 59973 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/59973] Creates a 32GB unused bss symbol with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Mike Hommey mh+gcc at glandium dot org --- Turns out this is bug 55650. *** This bug has been marked as a duplicate of bug 55650 ***
[Bug c++/56698] array subscript is above array bounds triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 --- Comment #5 from Mike Hommey mh+gcc at glandium dot org 2013-04-09 14:54:51 UTC --- As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=854105#c4, fileIndex is uint32_t, so 0 - 1 is UINT32_MAX, which makes the error valid. Now the question is why does it only show up with PGO with gcda info?
[Bug c++/56698] array subscript is above array bounds triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 --- Comment #3 from Mike Hommey mh+gcc at glandium dot org 2013-04-03 15:46:04 UTC --- Created attachment 29798 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29798 Preprocessed file This is the preprocessed file. In case that helps, the gcc it failed to build with is: http://puppetagain.pub.build.mozilla.org/data/repos/yum/releng/public/CentOS/6/x86_64/gcc472_0moz1-4.7.2-0moz1.x86_64.rpm The rpm spec used to create it: http://hg.mozilla.org/build/rpm-sources/file/396d84ab838e/gcc47/centos6-x86_64/gcc47.spec And the command line: /tools/gcc-4.7.2-0moz1/bin/g++ -o nsDiskCacheMap.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /builds/slave/try-l64-00/build/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -DIMPL_NS_NET -I/builds/slave/try-l64-00/build/netwerk/cache/../base/src -I/builds/slave/try-l64-00/build/netwerk/cache -I. -I../../dist/include -I/builds/slave/try-l64-00/build/obj-firefox/dist/include/nspr -I/builds/slave/try-l64-00/build/obj-firefox/dist/include/nss -fPIC -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fno-omit-frame-pointer -Werror -Wno-error=uninitialized -Wno-error=deprecated-declarations -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsDiskCacheMap.o.pp /builds/slave/try-l64-00/build/netwerk/cache/nsDiskCacheMap.cpp -save-temps=obj Error message: /builds/slave/try-l64-00/build/netwerk/cache/nsDiskCacheMap.cpp: In member function 'nsresult nsDiskCacheMap::WriteDataCacheBlocks(nsDiskCacheBinding*, char*, uint32_t)': /builds/slave/try-l64-00/build/netwerk/cache/nsDiskCacheMap.cpp:1042:68: error: array subscript is above array bounds [-Werror=array-bounds] I can't reproduce locally, so i suspect this also depends on the content of the gcda file, i'll try to get one.
[Bug c++/56698] array subscript is above array bounds triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 --- Comment #4 from Mike Hommey mh+gcc at glandium dot org 2013-04-03 18:35:14 UTC --- Created attachment 29800 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29800 nsDiskCacheMap.gcda I can reproduce with the preprocessed file and this gcda with gcc 4.7.2-5 from debian unstable with the following command line: g++ -o nsDiskCacheMap.o -c -fPIC -Wall -Wno-invalid-offsetof -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -std=gnu++0x -pipe -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fno-omit-frame-pointer -Werror -Wno-error=uninitialized -Wno-error=deprecated-declarations nsDiskCacheMap.ii
[Bug c++/56698] New: array subscript is above array bounds triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 Bug #: 56698 Summary: array subscript is above array bounds triggered on code that doesn't have that problem Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org I've been trying to get Firefox building with gcc 4.7 on the Mozilla build slaves, and with PGO enabled, I'm getting an array subscript is above array bounds error (we do uses -Werror in some places) on code that doesn't look like it would have the problem. It doesn't happen without PGO. The line of code it happens on is: https://hg.mozilla.org/mozilla-central/file/bcf09432affd/netwerk/cache/nsDiskCacheMap.cpp#l1028 mBlockFile is defined here: https://hg.mozilla.org/mozilla-central/file/bcf09432affd/netwerk/cache/nsDiskCacheMap.h#l570 kNumBlockFiles is defined here: https://hg.mozilla.org/mozilla-central/file/bcf09432affd/netwerk/cache/nsDiskCacheMap.h#l59 and CalculateFileIndex here. https://hg.mozilla.org/mozilla-central/file/bcf09432affd/netwerk/cache/nsDiskCacheMap.cpp#l1028/ With these, I see no way fileIndex - 1 can be above array bounds of mBlockFile[3], when fileIndex can only be 0, 1, 2 or 3. (and yes, there might be a problem when fileIndex is 0, but that's not above array bounds)
[Bug c++/56698] array subscript is above array bounds triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2013-03-23 18:11:16 UTC --- Interestingly, if I modify CalculateFileIndex to return 3 instead of 0, the error doesn't happen. So it might be a case of confusing gcc warning/error message.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Mike Hommey mh+gcc at glandium dot org 2013-03-10 09:20:05 UTC --- Thanks for tracking it down. *** This bug has been marked as a duplicate of bug 48308 ***
[Bug target/48308] [4.6/4.7/4.8 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #24 from Mike Hommey mh+gcc at glandium dot org 2013-03-10 09:20:05 UTC --- *** Bug 56561 has been marked as a duplicate of this bug. ***
[Bug target/56561] New: Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Bug #: 56561 Summary: Miscompilation with -Os -arm Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Created attachment 29609 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29609 Testcase (originally posted on http://gcc.gnu.org/ml/gcc/2013-03/msg00051.html) At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 build of Firefox for Android. We'd like to evaluate whether this bug is hitting us in more places than the one we spotted. To that end, we'd need to know what particular bug in GCC leads to this miscompilation. The attached file is the preprocessed source, slightly simplified, and with enough additions to allow it to be self-contained and with a main() that is able to act on the miscompilation being there or not. I was able to reproduce the miscompilation with both the GCC 4.6 from the Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens for any -march, with -marm, but not -mthumb. It happens at -Os but not -O2. The problematic assembly looks like the following. It corresponds to the C code after the second call to DER_SetUInteger in sftk_mkPrivKey:: bl DER_SetUInteger(PLT) mov r3, #0 cmp sl, r3 movne r0, #2 moveq r0, r3 sl/r10 is never set anywhere in the function, so we're getting random behaviour. This doesn't happen with GCC 4.7, which suggests it may be a known bug. Any ideas? (On an ARM host:) $ gcc -o pkcs11 pkcs11.i -marm -Os -fno-inline ./pkcs11 $ ./pkcs11 FAIL $ gcc -o pkcs11 pkcs11.i -marm -O2 -fno-inline ./pkcs11 $ ./pkcs11 PASS
[Bug c++/53829] New: Trivial static initializers are created for initialization with result of trivial static inline functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53829
Bug #: 53829
Summary: Trivial static initializers are created for
initialization with result of trivial static inline
functions
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mh+...@glandium.org
The most trivial example of the behaviour is this:
#include stdint.h
static inline uint64_t foo() { return 42; }
uint64_t f = foo();
G++ generates the following:
.filetest.cc
.section.text.startup,ax,@progbits
.p2align 4,,15
.type_GLOBAL__sub_I_f, @function
_GLOBAL__sub_I_f:
.LFB2:
.cfi_startproc
movq$42, f(%rip)
ret
.cfi_endproc
.LFE2:
.size_GLOBAL__sub_I_f, .-_GLOBAL__sub_I_f
.section.init_array,aw
.align 8
.quad_GLOBAL__sub_I_f
.globlf
.bss
.align 8
.typef, @object
.sizef, 8
f:
.zero8
.identGCC: (Debian 4.7.1-2) 4.7.1
.section.note.GNU-stack,,@progbits
For reference, clang++ generates the following:
.filetest.cc
.typef,@object # @f
.data
.globlf
.align8
f:
.quad42 # 0x2a
.sizef, 8
.section.note.GNU-stack,,@progbits
There are cases where g++ is able to generate code like clang++, but I can't
find one just now.
[Bug c++/53341] New: overloaded operator delete(void *) appear in object file even when not directly used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341
Bug #: 53341
Summary: overloaded operator delete(void *) appear in object
file even when not directly used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mh+...@glandium.org
Consider the following program:
-8--
#include algorithm
extern void moz_free(void *ptr);
__attribute__((always_inline)) inline
void operator delete(void* ptr) throw()
{
return moz_free(ptr);
}
int foo() {
return 42;
}
-8--
g++ -std=c++0x will put two symbols in the resulting object:
_ZdlPv and _Z3foov. The former is operator delete(void *)
This doesn't happen when including new instead of algorithm.
This doesn't happen without -std=c++0x.
This doesn't happen with operator new, operator new[], or operator delete[].
This doesn't happen when removing __attribute__((__externally_visible__)) from
/usr/include/c++/4.7/new. (added in bug 50594)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #127 from Mike Hommey mh+gcc at glandium dot org 2012-05-11 08:52:24 UTC --- (In reply to comment #126) (In reply to comment #124) Just for comparison, clang with -O4 runs only single threaded and does everything in memory (no streaming out). It uses 3.5GB of memory (peak) and takes 19 minutes to finish... Interesting. Micsofot's compiler is also barely in 4GB space, right? IIRC Mozilla recently switched to a 64-bit toolchain on windows, because the 32-bit linker ran out of memory. So they are above 4GB already. There is unfortunately no cross-linker in MSVC, so you can't link 32-bit binaries with a 64-bit toolchain. We're in the process of switching to 64-bits OS with a 32-its toolchain, which will allow an extra gigabyte of address-space. We've gone past the current 3GB limit a couple times now, at which point, we moved some stuff out of libxul. Before that, we hit the 2GB limit, at which point we used the /3GB option that allows for the extra GB.
[Bug c++/50442] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2011-09-17 06:21:28 UTC --- More specifically, r178746 from SVN gcc-4_6-branch is affected, while r178501 from the same branch is not.
[Bug other/49930] Need some adjustments for bionic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49930 --- Comment #4 from Mike Hommey mh+gcc at glandium dot org 2011-09-07 08:54:11 UTC --- (In reply to comment #3) So just the getpagesize remains? getpagesize is in libiberty, it shouldn't matter anymore (In reply to comment #2) Note that sincos() was introduced with Android 2.3. The initial version calls sin() then calls cos() so there's no immediate advantage. As you say, sincos() was introduced with Android 2.3, which means you can build native binaries for that target without the patch, but you can't build native binaries for older targets. There are too many Android 2.3 devices out there to just ignore the problem.
[Bug target/50022] New: [4.7 regression] incorrect condition in IT block when building mozilla code base for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022 Summary: [4.7 regression] incorrect condition in IT block when building mozilla code base for ARM Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Taking the attached preprocessed file, the following fails with latest gcc snapshot (4.7-20110806): $ g++ -std=gnu++0x -o test.o -c nsCookieService.i -mthumb -O3 -march=armv7-a -mfloat-abi=softfp /tmp/ccxA5O8X.s: Assembler messages: /tmp/ccxA5O8X.s:2694: Error: incorrect condition in IT block -- `ldrdlt r2,[r3]' /tmp/ccxA5O8X.s:2695: Error: thumb conditional instruction should be in IT block -- `smullge r2,r3,r3,r2' The error is slightly different when adding -fomit-frame-pointer: /tmp/ccSzGgKB.s: Assembler messages: /tmp/ccSzGgKB.s:2702: Error: thumb conditional instruction should be in IT block -- `ldrdlt r2,[r3]'
[Bug target/50022] [4.7 regression] incorrect condition in IT block when building mozilla code base for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2011-08-08 10:44:27 UTC --- Created attachment 24949 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24949 nsCookieService.i.xz
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #12 from Mike Hommey mh+gcc at glandium dot org 2011-08-02 15:22:20 UTC --- I get something that might be the same thing with gcc 4.6.1 and gold 2.21.53 with -flto when building the mozilla codebase with a custom android NDK. The line number is different, though: internal compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.c:242
[Bug other/49930] New: Need some adjustments for bionic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49930 Summary: Need some adjustments for bionic Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Created attachment 24879 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24879 Patch The following things are bionic specificities that the gcc source code doesn't handle well: - sincos is not supported - getpagesize is defined as an inline in the headers - prctl is defined with the prototype as per the linux manual page: int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5) and not prctl(int option, ...) as in glibc headers. With the attached patch, I was able to build gcc 4.6.1 for use with the Android NDK.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #101 from Mike Hommey mh+gcc at glandium dot org 2011-06-15 11:38:01 UTC --- (In reply to comment #100) Please note that this error only happens during a profiled build. Normal build seems to be OK. FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=664387
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #84 from Mike Hommey mh+gcc at glandium dot org 2011-04-12 10:53:44 UTC --- (In reply to comment #83) I am not sure if this is GCC bug or elfhack, but I would guess for elfhack actually. I guess you're right, because when I move the swap definitions: template class endian, typename R, typename T inline void Elf_Ehdr_Traits::swap(T t, R r) ... from elf.cpp to elfxx.h (where they actually belong) the link error vanishes. I'm not convinced they belong there. But wouldn't removing the inline keyword work equally well?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #78 from Mike Hommey mh+gcc at glandium dot org 2011-04-08 15:57:14 UTC --- (In reply to comment #75) (In reply to comment #74) Interesting. -O3 makes no difference for me. I will look into your dumps if I can spot something useful. ... If GCC fail to link even such a simple program as elfhack is, something pretty fundamental must go wrong. Perhaps it is linker bug. I had problems with older versions of gold. The failure only happens with -flto. And the reason is that: c++ -o host_elf.o -c -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -fpermissive -flto=4 -fuse-linker-plugin -fno-strict-aliasing -fshort-wchar -pthread -pipe -fexceptions -DNDEBUG -DTRIMMED -Os -I/var/tmp/mozilla-central/build/unix/elfhack -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/usr/include/nspr -I/usr/include/nss -I/usr/include/nspr /var/tmp/mozilla-central/build/unix/elfhack/elf.cpp apparently only compiles correctly in the -Os case. All other optimization switches (-O(0..3) or without -O) lead to the eventual link failure above. And it happens with both gnu-ld and gold (2.21.51.20110402). What matters is what is used to build/link test.so, not elfhack itself, and from the look at the command line in comment 70, you're building test.so with unexpected things. It is not meant to be optimized. So, some more variables tweaking would apparently be required in build/unix/elfhack/Makefile.in.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #45 from Mike Hommey mh+gcc at glandium dot org 2011-02-12 09:32:34 UTC --- Can you try mozilla-central revision 19f13dea4d4a?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #43 from Mike Hommey mh+gcc at glandium dot org 2011-02-10 17:41:53 UTC --- (In reply to comment #42) (In reply to comment #41) Segfaults or aborts ? Segfaults: === === If you get failures below, please file a bug describing the error === and your environment (compiler and linker versions), and use === --disable-elf-hack until this is fixed. === /home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack/elfhack -b test.so test.so: Reduced by 12128 bytes # Fail if the backup file doesn't exist [ -f test.so.bak ] # Fail if the new library doesn't contain less relocations [ $(objdump -R test.so.bak | wc -l) -gt $(objdump -R test.so | wc -l) ] /home/mjambor/gcc/icln/inst/bin/gcc -o dummy dummy.o test.so # Will either crash or return exit code 1 if elfhack is broken LD_LIBRARY_PATH=/home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack /home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack/dummy make[6]: *** [libs] Segmentation fault make[6]: Leaving directory `/home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack' ...and very early on it seems: (gdb) bt #0 0x77ff7040 in frame_dummy () from /home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack/test.so #1 0x77ff6f5e in _init () from /home/mjambor/mozilla/mc2/objdir-ff-release/build/unix/elfhack/test.so #2 0x77ffa710 in ?? () #3 0x77debe18 in call_init () from /lib64/ld-linux-x86-64.so.2 #4 0x77debf47 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #5 0x77ddeb3a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 Ah, so this is a crash of the test, not of elfhack. Could you attach both test.so and test.so.bak files ?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #44 from Mike Hommey mh+gcc at glandium dot org 2011-02-10 17:43:04 UTC --- (In reply to comment #43) Ah, so this is a crash of the test, not of elfhack. Could you attach both test.so and test.so.bak files ? Actually, it would be better to just do that on bugzilla.mozilla.org. (please Cc :glandium there)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #41 from Mike Hommey mh+gcc at glandium dot org 2011-02-09 14:34:08 UTC --- (In reply to comment #40) I have just checked-out mozilla-central entirely by doing hg clone http://hg.mozilla.org/mozilla-central/ and the elfhack test still segfaults for me (with lto). Segfaults or aborts ?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #39 from Mike Hommey mh+gcc at glandium dot org 2011-02-07 18:40:22 UTC --- (In reply to comment #38) Created attachment 23253 [details] failing testcase With current mainline and top of tree mozilla, things seems to go well, sqlite issues are gone. I now however get elfhack fault: jh@evans:/abuild/jh/build-mozilla-new9/build/unix/elfhack /abuild/jh/build-mozilla-new9/build/unix/elfhack/elfhack -b test.so test.so: terminate called after throwing an instance of 'std::runtime_error' what(): Section index out of bounds Aborted (core dumped) I am attaching test.so I get to see if it is elfhack miscomplation or the binary. That could well be https://bugzilla.mozilla.org/show_bug.cgi?id=629638 Can you check with a changeset newer than http://hg.mozilla.org/mozilla-central/rev/2772a0cf36d1 ?
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #9 from Mike Hommey mh+gcc at glandium dot org 2010-12-11 14:36:36 UTC --- (In reply to comment #7) Hi, thanks for testcase. What I was concerned about is the static linking case. When you have static library with constructors and main program with constructors, my understanding was that the reverse execution order of .ctor section was designed in a way so library even in this case is initialized first. This explanation doesn't stand: for instance, ARM EABI exclusively uses .init_array, and the execution order for those is forward. And when linking static libraries, the order of the function pointers in the section is strictly growing, which means libraries are being initialized last.
[Bug target/46770] New: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Summary: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Considering .init_array/.fini_array has been supported by glibc for 11 years ( http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fcf70d4114db9ff7923f5dfeb3fea6e2d623e5c2;hp=3f3822198993be18d4d9ccb1593eea274dbd2ba0 ), it would make sense to use these instead of .ctors/.dtors, on systems supporting them.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2010-12-02 19:24:44 UTC --- Using .init_array/.fini_array instead of .ctors/.dtors removes the need for the associated (relative) relocations, and avoids the backwards disk seeks on startup (since while .ctors are processed backwards, .init_array is processed forward)
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #10 from mh+gcc at glandium dot org 2010-09-16 07:43 --- (In reply to comment #9) Created an attachment (id=21806) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21806action=view) [edit] testcase Here you go. This passes at -O0 but fails at -O2. Note that the testcase requires = 7 args to the test function, to force the last arg to spill onto the stack; also an inner (non-inlined) function call, to force that single stack arg to be zero-extended to word size and overwrite the flags. Another way to achieve the test without relying on the compiler optimization would be to use int or size_t arguments, but pass bools through ffi_call. This may not work on all architectures, though. Also, interestingly, the original patch doesn't trigger any testsuite failure. Maybe the various cls tests should be extended to get a first dummy argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #9 from mh+gcc at glandium dot org 2010-09-15 11:45 --- Created an attachment (id=21798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21798action=view) Reduced testcase Both issues Taras mentioned are actually separated. One is an actual bug in ffi (to be filed), the other one is an optimization issue with gcc. I reduced the problematic code to the attached code, which prints foo with -O1 (and more), and bar with -O0, with gcc 4.5.1. gcc 4.4 compiled code correctly prints bar with any optimization level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #10 from mh+gcc at glandium dot org 2010-09-15 11:53 --- Please note this actually only happens on x86. (I would change the summary and target if I could) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #11 from mh+gcc at glandium dot org 2010-09-15 12:05 --- Created an attachment (id=21799) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21799action=view) Reduced testcase Inlining JSVAL_TO_PRIVATE by hand still makes it break, and reduces the testcase further. -- mh+gcc at glandium dot org changed: What|Removed |Added Attachment #21798|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #12 from mh+gcc at glandium dot org 2010-09-15 12:11 --- FWIW, it's still broken on a gcc trunk snapshot from the 28th of august. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug libffi/45677] New: Bad stack allocation for ffi function calls on x86-64
The stack space allocated by ffi_call for the non-register arguments is not big enough (and not properly aligned) when calling the target function, and depending on what the called function does with the stack, it can end up overwriting ffi_call_unix64's stack. A case where this occurred is with a target function with a lot of arguments, the last one being a boolean. The target function itself, depending on gcc version and optimization level would rewrite all boolean arguments with padding to pass them to another function, and the allocated stack space for that was insufficient, such that rewriting this last boolean argument would actually overflow, overwriting the flags in ffi_call_unix64 and making the returned value ignored. See https://bugzilla.mozilla.org/show_bug.cgi?id=594611 -- Summary: Bad stack allocation for ffi function calls on x86-64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mh+gcc at glandium dot org GCC target triplet: x86_64-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #1 from mh+gcc at glandium dot org 2010-09-15 12:21 --- Created an attachment (id=21800) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21800action=view) Fix stack allocation for ffi function calls on x86-64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #15 from mh+gcc at glandium dot org 2010-09-15 12:47 ---
Note that the original code doesn't use char *. I used char * to make it easily
visible with a printf. Actually, just writing
void foo(jsval_layout l, void *s2) {
jsval_layout m;
m.asBits = l.asBits;
void ** data = (void**)m.ptr;
*data = s2;
}
exhibits the problem, afaics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #16 from mh+gcc at glandium dot org 2010-09-15 12:52 --- The real code where this gets problematic: http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5615 The function it calls: http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5542 http://mxr.mozilla.org/mozilla-central/source/js/src/jsapi.h#281 http://mxr.mozilla.org/mozilla-central/source/js/src/jsval.h#799 http://mxr.mozilla.org/mozilla-central/source/js/src/jsval.h#506 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #18 from mh+gcc at glandium dot org 2010-09-15 13:14 --- (In reply to comment #17) Thus, as a workaround you should make sure the asBits field matches pointer-size (so for example use uintptr_t isntead of uint64_t). which is not possible in the original code, as the union is a bit more complicated than in the reduced testcase: http://mxr.mozilla.org/mozilla-central/source/js/src/jsval.h#274 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #20 from mh+gcc at glandium dot org 2010-09-15 13:41 --- (In reply to comment #19) Another workaround is to use -fno-tree-pta. Doesn't work here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #22 from mh+gcc at glandium dot org 2010-09-15 13:52 --- (In reply to comment #21) For the original code? Then your reduced testcase is different from the original problem. It doesn't work for the reduced testcase here, with gcc 4.5.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #25 from mh+gcc at glandium dot org 2010-09-15 14:01 --- Oh, I was trying with -O2, yes, it works with -O1 -fno-tree-pta. Let me try on the original code, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #7 from mh+gcc at glandium dot org 2010-09-15 18:13 --- Nice catch. BTW I read recently that gcc 4.5 assumes 16 bytes stack alignment, is that x86 only or does that apply to x86-64 too ? (in which case we'd need to be careful about that as well) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug c++/43232] New: .eh_frame section created despite -fno-exceptions
With a source as simple as the following:
-8
int foo(int a, int b) {
return a + b;
}
-8
a .eh_frame section is created on x86-64 when using -fno-exceptions. The
section is *not* created on x86.
on x86-64:
$ g++ -o test.o -c test.cpp -fno-exceptions
$ objdump -h test.o
test.o: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0015 0040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0058 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0058 2**2
ALLOC
3 .comment 001d 0058 2**0
CONTENTS, READONLY
4 .note.GNU-stack 0075
2**0
CONTENTS, READONLY
5 .eh_frame 0038 0078 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
on x86:
$ g++ -o test.o -c test.cpp -fno-exceptions
$ objdump -h test.o
test.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000e 0034 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0044 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0044 2**2
ALLOC
3 .comment 001d 0044 2**0
CONTENTS, READONLY
4 .note.GNU-stack 0061 2**0
CONTENTS, READONLY
The section is created on x86 when not using -fno-exceptions, which is not a
surprise.
--
Summary: .eh_frame section created despite -fno-exceptions
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43232
[Bug c++/43232] .eh_frame section created despite -fno-exceptions
--- Comment #2 from mh+gcc at glandium dot org 2010-03-02 17:37 --- (In reply to comment #1) That's because x86-64 defaults to -fasynchronous-unwind-tables. You really want that by default on x86_64, as frame pointer is usually omitted. Why would you want -fasynchronous-unwind-tables if you don't have exceptions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43232
[Bug c++/43232] .eh_frame section created despite -fno-exceptions
--- Comment #4 from mh+gcc at glandium dot org 2010-03-02 17:48 --- Because it can be used for the backtrace when debugging. Without a frame pointer on x86/x86_64, you cannot get a real backtrace without unwinding info. So, in case I build with -g, I can just use -fno-asynchronous-unwind-tables safely ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43232
[Bug c++/43232] .eh_frame section created despite -fno-exceptions
--- Comment #6 from mh+gcc at glandium dot org 2010-03-02 17:56 --- (In reply to comment #5) (In reply to comment #4) So, in case I build with -g, I can just use -fno-asynchronous-unwind-tables safely ? Yes it is safe but not recommended though. I should mention the x86_64 elf ABI requires this section to be created. Even with -fno-asynchronous-unwind-tables, the section is created, though empty most of the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43232
[Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used
--- Comment #2 from mh+gcc at glandium dot org 2008-05-11 09:18 --- Usually, when you're using visibility hidden, that means you want to avoid exporting a lot of cruft symbols from a shared library... that the std:: namespace is always visibility default is an annoyance. Especially considering the set of exported symbols change with optimization, since some of these might end up inlined: $ g++-4.3 -O3 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o foo.so foo.cpp $ objdump -T -C foo.so | grep std 0780 w DF .text 02fe Basevoid std::__introsort_loopint*, long(int*, int*, long) $ g++-4.3 -O2 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o foo.so foo.cpp $ objdump -T -C foo.so | grep std 0a40 w DF .text 00a6 Basevoid std::__insertion_sortint*(int*, int*) 08d0 w DF .text 0161 Basevoid std::__introsort_loopint*, long(int*, int*, long) 07e0 w DF .text 00eb Basevoid std::__adjust_heapint*, long, int(int*, long, long, int) $ g++-4.3 -O1 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o foo.so foo.cpp $ objdump -T -C foo.so | grep std 0c65 w DF .text 0063 Basevoid std::make_heapint*(int*, int*) 0ee0 w DF .text 0051 Basevoid std::__final_insertion_sortint*(int*, int*) 0b52 w DF .text 0024 Basevoid std::__unguarded_linear_insertint*, int(int*, int) 0b76 w DF .text 0053 Basevoid std::__push_heapint*, long, int(int*, long, long, int) 0b10 w DF .text 0042 Baseint* std::__unguarded_partitionint*, int(int*, int*, int) 0d21 w DF .text 0053 Basevoid std::sort_heapint*(int*, int*) 0cc8 w DF .text 0059 Basevoid std::__heap_selectint*(int*, int*, int*) 0e72 w DF .text 006a Basevoid std::__insertion_sortint*(int*, int*) 0d80 w DF .text 00f2 Basevoid std::__introsort_loopint*, long(int*, int*, long) 0bc9 w DF .text 009c Basevoid std::__adjust_heapint*, long, int(int*, long, long, int) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
[Bug c++/36022] New: stl templates exported as weak symbols though visibility hidden is used
With the following foo.cpp sample:
#include algorithm
__attribute__((visibility(default))) void foo() {
int array[] = { 23, 5, -10, 0, 0, 321, 1, 2, 99, 30 };
int elements = sizeof(array) / sizeof(array[0]);
std::sort(array, array + elements);
}
Building with the following command line:
g++-4.3 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o foo.so
foo.cpp
Leads to internals being exposed, which is unexpected:
objdump -T -C test2.so | grep std
136d w DF .text 003a Basevoid
std::__unguarded_insertion_sortint*(int*, int*)
1b18 w DF .text 0057 Basevoid
std::sortint*(int*, int*)
147f w DF .text 000e Base
std::__niter_baseint*, false::__b(int*)
190b w DF .text 0021 Basestd::__lg(long)
1324 w DF .text 0049 Basevoid
std::__unguarded_linear_insertint*, int(int*, int)
141f w DF .text 0060 Baseint*
std::__unguarded_partitionint*, int(int*, int*, int)
1674 w DF .text 0088 Basevoid
std::make_heapint*(int*, int*)
1400 w DF .text 001f Basevoid
std::iter_swapint*, int*(int*, int*)
13b5 w DF .text 002c Basevoid
std::swapint(int, int)
16fc w DF .text 0054 Basevoid
std::__pop_heapint*(int*, int*, int*)
19bc w DF .text 004f Baseint*
std::__copy_move_backward_a2false, int*, int*(int*, int*, int*)
1a4b w DF .text 0079 Basevoid
std::__insertion_sortint*(int*, int*)
1a0b w DF .text 0040 Baseint*
std::copy_backwardint*, int*(int*, int*, int*)
1750 w DF .text 005d Basevoid
std::__heap_selectint*(int*, int*, int*)
1284 w DF .text 00a0 Baseint const
std::__medianint(int const, int const, int const)
17ad w DF .text 002b Basevoid
std::pop_heapint*(int*, int*)
152e w DF .text 0146 Basevoid
std::__adjust_heapint*, long, int(int*, long, long, int)
13a7 w DF .text 000e Base
std::__miter_baseint*, false::__b(int*)
180f w DF .text 0034 Basevoid
std::partial_sortint*(int*, int*, int*)
17d8 w DF .text 0037 Basevoid
std::sort_heapint*(int*, int*)
1991 w DF .text 002b Baseint*
std::__copy_move_backward_afalse, int*, int*(int*, int*, int*)
1ac4 w DF .text 0054 Basevoid
std::__final_insertion_sortint*(int*, int*)
1843 w DF .text 00c8 Basevoid
std::__introsort_loopint*, long(int*, int*, long)
192c w DF .text 0065 Baseint*
std::__copy_move_backwardfalse, true,
std::random_access_iterator_tag::__copy_move_bint(int const*, int const*,
int*)
13e1 w DF .text 001f Basevoid
std::__iter_swaptrue::iter_swapint*, int*(int*, int*)
148d w DF .text 00a1 Basevoid
std::__push_heapint*, long, int(int*, long, long, int)
FYI: g++-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure linux gnu
Thread model: posix
gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3)
(it also happens with g++-4.2 from debian (4.2.3))
--
Summary: stl templates exported as weak symbols though visibility
hidden is used
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
