[Bug c/57923] New: ICE in handle_braces (gcc.c) at -O3 (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57923
Bug ID: 57923
Summary: ICE in handle_braces (gcc.c) at -O3 (both 32-bit and
64-bit modes)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux (both 32-bit and 64-bit modes). This is a regression from
4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130718 (experimental) [trunk revision 201019] (GCC)
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$ gcc-trunk -O3 small.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40c95d execute
../../gcc-trunk/gcc/gcc.c:2824
0x40ccb4 do_spec_1
../../gcc-trunk/gcc/gcc.c:4616
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
0x40d3ea do_spec_1
../../gcc-trunk/gcc/gcc.c:5270
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
0x40d3ea do_spec_1
../../gcc-trunk/gcc/gcc.c:5270
0x40cf3b do_spec_1
../../gcc-trunk/gcc/gcc.c:5375
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
0x40d3ea do_spec_1
../../gcc-trunk/gcc/gcc.c:5270
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
0x40d3ea do_spec_1
../../gcc-trunk/gcc/gcc.c:5270
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
0x40d3ea do_spec_1
../../gcc-trunk/gcc/gcc.c:5270
0x40f841 process_brace_body
../../gcc-trunk/gcc/gcc.c:5873
0x40f841 handle_braces
../../gcc-trunk/gcc/gcc.c:5787
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
-
char a;
foo (int **p)
{
int b;
for (;;) {
int c[1] = {};
unsigned *d = &c[0];
for (b=7; b; b--)
**p &= --*d >= a;
}
}
$
[Bug fortran/57924] New: -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57924 Bug ID: 57924 Summary: -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jahns at dkrz dot de Created attachment 30521 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30521&action=edit source file to trigger the warning When compiling a program that generates an array temporary, and the compiler is instructed to 1. generate warnings for array temporaries 2. warnings are elevated to errors 3. array temporary warnings are explicitly set to non-errors compilation still aborts once a corresponding warning is encountered. I've attached a source file + Makefile to demonstrate. I've also tested gfortran 4.6.3. All my tests were done on a Debian system.
[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57924 --- Comment #1 from Thomas Jahns --- Created attachment 30522 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30522&action=edit Makefile giving flags Add Makefile missing from original report.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #18 from Paulo J. Matos --- I notice(In reply to Brooks Moses from comment #12) > > Now, if this replacement still happens when you compile with -nostdlib, that > would be a bug since it becomes legal code in that case. But that's > somewhat of a separate issue and should be filed separately if it happens. > (We should arguably also have a test for it, if we don't already.) I noticed this in the gcc testsuite with my port. File ./gcc.c-torture/execute/builtins/lib/memset.c contains an implementation of memset called memset and gcc goes into recursion when it finds this for the reasons mentioned above. This causes builtin/memset test to fail.
[Bug c++/57925] New: discrete_distribution can be improved to O(1) per sampling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57925
Bug ID: 57925
Summary: discrete_distribution can be improved to O(1) per
sampling
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yangzhe1990 at gmail dot com
Current implementation of discrete_distribution employs a strait-forward
algorithm by partial_sum and std::lower_bound, which is an O(log n) per sample
algorithm. It can be improved to an O(1) per sampling, by using the pair and
alias method, just like what GSL did.
The (log n) factor of std::lower_bound is large even for n = 3.
The algorithm is relatively simple, and you will definitely enjoy implementing
it. Here's my sample code. Although it's quite informal, but I hope you can be
convinced that the effort of this improvement is small but its so great to have
it in the STL.
class my_discrete_distribution {
private:
vector paired;
vector weight;
uniform_real_distribution u;
public:
template
my_discrete_distribution(InputIterator begin, InputIterator end)
{
for (; begin != end; ++begin)
weight.push_back(*begin);
int size = weight.size();
vector small(size);
int small_cnt = 0;
for (int i = 0; i < size; ++i) {
weight[i] *= size;
if (weight[i] <= 1)
small[small_cnt++] = i;
}
paired.resize(size);
for (int i = 0; i < size; ++i)
paired[i] = i;
for (int i = 0; i < size; ++i) {
double w = weight[i];
if (w > 1) {
int j; int p;
for (j = small_cnt - 1; j >= 0 && w > 1; --j) {
p = small[j];
paired[p] = i;
w -= (1 - weight[p]);
}
small[j + 1] = i;
small_cnt = j + 2;
weight[i] = w;
}
}
u.param(uniform_real_distribution(0.0, size + 0.0).param());
}
template
int operator() (RNG &rng) {
const double a = u(rng);
int int_part = (int)a;
if (a - int_part >= weight[int_part])
return paired[int_part];
else
return int_part;
}
};
[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885 --- Comment #5 from François Dumont --- The biggest performance regression introduced in version 4.8 is coming from an attempt to enhance unordered containers global performances. The data model has been modified because the erase operation had become very expensive in some situations since the Standard requires it to return the iterator following the erased one. To do so we moved from a vector like data model to a combination of vector for buckets and a single forward_list for elements. In the former model when erasing an element we needed to look for the next non-empty bucket potentially looping through a lot of empty ones resulting in very bad performances. In the new model all elements are linked to the next one and the access is direct. The drawback is that when looking for an element you need to get its bucket and then loop on the bucket element. In the former model the loop end condition was the forward_list::end(). In the new model you need to compute the next element bucket to check that you can stop because you moved to another bucket. This explains the additional divq instruction and the performance hint. Of course your bench is isolating the main drawback of the new data model. There are benches in libstdc++ testsuite/performance that compares tr1 and std implementations and globally std ones are better even if you can already see the performance hint you are reporting here. So we chose to move from a data model very good on some use cases but very bad on some others to a data model good in all situations but not very good anymore in your use case. I agree however that your use case is quite important and the only way I can think of to restore its performance would be to introduce a concept of empty node in the data model so that we detect end of bucket without relying on a divq instruction. The drawback will be a memory overhead, one bool per node to flag empty/non-empty node and an additional empty node per non empty bucket. This is perhaps more acceptable for such a container which purpose is not to be memory efficient but rather performance efficient. The performance hint of version 4.9 comes from C++11 allocator conformity. I will avoid details but for exception safety reasons I had to correctly manage an unordered container instance having no bucket allocated. In this case the number of bucket is 0 and doing a 'hash code % 0' operation is bad so I had to introduce some checks on the bucket number at the beginning of some methods like the find one. It explains the additional testq operation which is I fear unavoidable for a Standard conforming implementation.
[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57924 --- Comment #2 from Thomas Jahns --- Just tried with gfortran 4.8.1 (an Ubuntu 13.04 test release). The problem persists.
[Bug driver/51844] configuring with --with-gxx-include-dir= adds a relative (non-existing) C++ include dir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51844
Sylpheed changed:
What|Removed |Added
CC||typesylph at gmail dot com
--- Comment #5 from Sylpheed ---
Please try these patches for trunk(4.9.0).
1. gcc/gcc.c
line 2548
< if (sysroot_len > 0
---
> if (sysroot_len > 1
2. gcc/incpath.c
line 182
< if (sysroot_len > 0 && sysroot[sysroot_len - 1] == DIR_SEPARATOR)
---
> if (sysroot_len > 1 && sysroot[sysroot_len - 1] == DIR_SEPARATOR)
There patch is for 'host-compiling' with '--withsysroot=/'.
Anyother promrems defferent env('cross-compiling') the other problem may be.
[Bug c++/57926] New: Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Bug ID: 57926 Summary: Atomic functions broken with C++ but not C? Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lailavrazda1979 at gmail dot com Note that this possible bug does not trigger with GCC, only G++. Try compiling the code in the attachment with g++. It'll give strange errors, including complaining that an argument must be a non-void pointer when it IS in fact, a non-void pointer.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #1 from lailavrazda1979 at gmail dot com --- Created attachment 30523 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30523&action=edit Code triggering the bug
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-07-18
Ever confirmed|0 |1
Severity|major |normal
--- Comment #2 from Jonathan Wakely ---
The test is broken, i should be the same type as Mutex. This should compile
though:
long Mutex[1];
int AcquireLogMutex(void)
{
return __atomic_exchange_n(Mutex, 1, __ATOMIC_SEQ_CST);
}
void ReleaseLogMutex(void)
{
long i = 0;
__atomic_store(Mutex, &i, __ATOMIC_SEQ_CST);
}
G++ doesn't do the array-to-pointer conversion
There's a simple workaround: just use (long*)Mutex
[Bug middle-end/57805] Wasted work in write_roots()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on trunk.
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 Laurent Aflonsi changed: What|Removed |Added CC||laurent.alfonsi at st dot com --- Comment #58 from Laurent Aflonsi --- Created attachment 30524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30524&action=edit functional regression
[Bug rtl-optimization/57810] Wasted work in validate_const_int()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on trunk.
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #59 from Laurent Aflonsi --- I have a functional regression due to this improvement when we are compiling the enclosed example in -O2. $ sh-superh-elf-gcc -O2 pr51244-20-main.c pr51244-20.c $ sh-superh-elf-run a.out FAIL Thus, the code is transformed from : _get_request: mov.l@(12,r4),r1 tstr1,r1 bt.L2 mov.l@(4,r4),r2 tstr2,r2 mov#-1,r2 negcr2,r2 .L3: tstr2,r2 bt/s.L11 mov#-100,r0 mov#1,r2 [...] to : _get_request: mov.l@(12,r4),r1 tstr1,r1 bt.L2 mov.l@(4,r4),r2 tstr2,r2 mov#-1,r2 negcr2,r2 .L3: bf/s.L11 mov#-100,r0 mov#1,r2 [...] With the inputs encoded in the main function, we are supposed to follow the simpliest flow (no jump), but when this optimization is enabled, we are jumping to L11 to to the bt -> bf transfrmation. Could you please look at it ? Thanks Laurent
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-18 Ever confirmed|0 |1 --- Comment #9 from Jan Hubicka --- Yes, this is OK. I wonder if we should output direct calls to autoinlines we introduce late (i.e. if the error should be moved to expander). That would of course break the Firefox again, but I think once we decided to error on uninlined calls we should be consistent in it... Honza
[Bug target/57927] New: -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 Bug ID: 57927 Summary: -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch for instance mkdir scimark2TMP cd scimark2TMP wget http://math.nist.gov/scimark2/scimark2_1c.zip . unzip scimark2_1c.zip c++ -S LU.c -O3 -march=native -o LU.native -v c++ -S LU.c -O3 -march=core-avx2 -o LU.avx2 -v diff LU.native LU.avx2 if you run the benchmark gcc -O3 -march=core-avx2 *.c -lm; ./a.out 5 gcc -O3 -march=native *.c -lm; ./a.out 5 "core-avx2" is better than "native"
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So what exactly does the -v print?
[Bug c/57928] New: Doesn't compile with ISL 0.12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57928 Bug ID: 57928 Summary: Doesn't compile with ISL 0.12 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lailavrazda1979 at gmail dot com You guys consider checking for 0.10 and up instead of adding an explicit check for every new release?
[Bug java/57929] New: gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57929 Bug ID: 57929 Summary: gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org Created attachment 30525 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30525&action=edit original preprocessed source code Hi, this is a forward for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711558 which is an ICE trying to bootstrap gcj-4.8 that I *think* remember seeing for gcj-4.7 (but not gcj-4.6 which works fine) already too, on the Debian/m68k Linux 3.x (NPTL, atomics via syscall) platform. The problem is now that the gcj part got merged into the main gcc source package and this is kinda holding up our entire toolchain update (also, I think gcj-4.6 got removed from sid). Since I was unable to get OpenJDK/zero working either, gcj is our only hope to keep Linux/m68k spinning so I’m hoping that $skilled_people will have a look at it. Preprocessed source attached here, too (xz compressed, hope that’s ok).
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 --- Comment #2 from vincenzo Innocente --- COLLECT_GCC_OPTIONS='-S' '-O3' '-march=native' '-o' 'LU.native' '-v' '-shared-libgcc' /afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -quiet -v -D_GNU_SOURCE LU.c -march=corei7-avx -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=generic -quiet -dumpbase LU.c -auxbase-strip LU.native -O3 -version -o LU.native GNU C++ (GCC) version 4.9.0 20130718 (experimental) [trunk revision 201034] (x86_64-unknown-linux-gnu) versus COLLECT_GCC_OPTIONS='-S' '-O3' '-march=core-avx2' '-o' 'LU.avx2' '-v' '-shared-libgcc' /afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -quiet -v -D_GNU_SOURCE LU.c -quiet -dumpbase LU.c -march=core-avx2 -auxbase-strip LU.avx2 -O3 -version -o LU.avx2 GNU C++ (GCC) version 4.9.0 20130718 (experimental) [trunk revision 201034] (x86_64-unknown-linux-gnu)
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 --- Comment #3 from Marc Glisse --- gcc/config/i386/driver-i386.c host processor detection apparently hasn't been updated for those recent processors yet. You could look for this code: case 0x2d: /* Sandy Bridge. */ cpu = "corei7-avx"; break; and add nearby: case 0x3a: /* Ivy Bridge. */ cpu = "core-avx2"; break; Also, a few lines below, before "if (has_avx)", one could test has_avx2 and use core-avx2 as a default in that case.
[Bug c++/57930] New: missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930
Bug ID: 57930
Summary: missing destructor call after thrown exception in
C++11 list initialization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mmehlich at semanticdesigns dot com
In the example below, a subobject of type B is constructed but not destructed
when an exception is thrown during construction of the enclosing object of
type A after subobject of type B has been constructed.
extern "C" int printf(const char *,...);
struct B {
B(int,int) { printf("CB %p\n",this); }
B(const B&) { printf("const CB %pn\n",this); }
B(B&&) { printf("const CB %pn\n",this); }
~B() { printf("B %p\n",this); }
};
struct C {
int c;
int c2;
};
struct A {
struct B b;
struct C c;
};
A test() {
//const A a1 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B
called
//const A &a2 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B not
called
return { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B not called
};
int main() {
try {
test();
} catch (...) {
}
}
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 --- Comment #10 from Sriraman Tallam --- Patch committed. This should fix this. Sri
[Bug c/57931] New: There are superfluous movw instructions in when using GCC-AVR (WinAVR) asm code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57931 Bug ID: 57931 Summary: There are superfluous movw instructions in when using GCC-AVR (WinAVR) asm code. Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: NickParker at Eaton dot com Created attachment 30526 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30526&action=edit C code and a listing There are superfluous movw instructions in when using GCC-AVR (WinAVR) asm code. Might as well make some tighter code here!
[Bug c++/57930] missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930 --- Comment #1 from Jonathan Wakely --- I'm pretty sure there's an existing bug report about this, opened by Jason.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Markus Trippelsdorf --- (In reply to Sriraman Tallam from comment #10) > Patch committed. This should fix this. > > Sri Thanks Sri.
[Bug c/57933] New: function dwf_regno accesses dbx_register_map beyond its upper limit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57933
Bug ID: 57933
Summary: function dwf_regno accesses dbx_register_map beyond
its upper limit
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compiling the following code with -m32 option
the gcc front end array extern int const
dbx_register_map[FIRST_PSEUDO_REGISTER]
declared in i386.h is accessed beyond its upper limit
in function dwf_regno in dwarf2cfi.c:898.
This is because FIRST_PSEUDO_REGISTER is 53,
while REGNO (reg) is 61.
I double checked this one putting the statement
gcc_assert ( REGNO (reg) < FIRST_PSEUDO_REGISTER );
immediately before
return DWARF_FRAME_REGNUM (REGNO (reg));
in dwarf2cfi.c:898.
The macro DWARF_FRAME_REGNUM is defined as macro DBX_REGISTER_NUMBER.
I have an x86-64 CPU with Linux Fedora 19 64 bits.
Compiler command: gcc -S -m32 p.c
/* Code begins /
void sigsetjmp (void);
typedef struct {} *S;
void __attribute__((__stdcall__)) f(S);
void __attribute__((__force_align_arg_pointer__))
g(S hS)
{
sigsetjmp ();
f(hS);
}
/* Code ends ***/
p.c: In function ‘g’:
p.c:13:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:898
}
^
0x885bc7 dwf_regno
../../gcc-4.8.1/gcc/dwarf2cfi.c:898
0x88bb7c dwarf2out_frame_debug
../../gcc-4.8.1/gcc/dwarf2cfi.c:1990
0x88d80e scan_insn_after
../../gcc-4.8.1/gcc/dwarf2cfi.c:2340
0x88e2ac scan_trace
../../gcc-4.8.1/gcc/dwarf2cfi.c:2497
0x88e413 create_cfi_notes
../../gcc-4.8.1/gcc/dwarf2cfi.c:2541
0x890096 execute_dwarf2_frame
../../gcc-4.8.1/gcc/dwarf2cfi.c:2898
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[vitti winesan]$
[Bug c/57932] New: Aligned stack wastes more than k bytes, if preferred stack boundary k=2**n, n>=4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57932
Bug ID: 57932
Summary: Aligned stack wastes more than k bytes, if preferred
stack boundary k=2**n, n>=4
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: meisenmann@fh-salzburg.ac.at
I have noticed that in many cases the "waste" of the local stack exceeds the
minimum/optimal value, as specified by the option '-mpreferred-stack-boundary'.
For example following code:
extern int TestCall(int);
int Caller(int val)
{
return TestCall(val);
}
, produces the assembler-code:
pushl%ebp
movl%esp, %ebp
subl$24, %esp
movl8(%ebp), %eax
movl%eax, (%esp)
callTestCall
leave
ret
Note: Compiled with a i386-elf cross compiler GCC 4.8.1, based on MinGW;
The same or a similar result can be produced also with i386-elf-gcc 4.6.4 and
(origin) MinGW version 4.7.2.
The stack-adjustment (subl $24, %esp) has to consider the return-address,
backup of previous frame-pointer (maybe pushed registers), local variables and
arguments [...], an has to fulfill the requested stack-boundary.
In this case: -mpreferred-stack-boundary=4 (and implies
-mincoming-stack-boundary=4).
But the operand/value 24 is not the optimal value to fulfill a stack-boundary,
which is a multiple of k=16 byte (k=2**n, where n = 4). The minimal (optimal)
value should 8; I.e. 16 - 4 (return-address) - 4 (backup of ebp), also to
provide at least 4 remaining byte for the argument (to call 'TestCall').
Further investigations with different values of '-mpreferred-stack-boundary'
has shown, that the wasted gap exceeds k = 2**n bytes, if n >= 4.
If I use '-mpreferred-stack-boundary=3' the assembler code contains 'subl $8,
%esp', fulfilling the requested 8 byte-boundary. Assuming that the incoming
stack is already aligned to a multiple of 16 this would also ensure a (local)
stack-boundary which is a multiple of 16 ...
A more mathematical view:
Give is a incoming and preferred stack-boundary of k = 2**n (where n >= 2),
the assembler-output will contain a instruction of 'subl $A, %esp' and the
unussed (wasted) stack is less than k.
With another incoming and preferred stack-boundary k' = 2**n' and n' > n,
the used operand A' (of the stack-adjustment instruction) will be (optimal):
A <= A' <= 2**n' - 2**n - A,
or the difference of A' - A is less or equal to 2**n' - 2**n
(never exceeds the difference of the preferred stack-alignments).
A better "test-case" is to use '-mpreferred-stack-boundary=8':
With this simple code-sample above, I have assumed that the operand of the
stack-adjustment does never excceds 256 (bytes), but result is:
subl$504, %esp
The requirement of stack-alignment to a 256 byte-boundary (assuming that
incomming stack is already aligned) is fulfilled. But there's an "extra" wasted
stack-area of 256 byte. In this case (in context to my understanding of
stack-alignment), the operand should be 248 (I.e. 256 - 8).
