[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Eric Botcazou changed: What|Removed |Added Summary|[4.7/4.8 Regression] 'asm' |[4.7/4.8 Regression] 'asm' |operand requires impossible |operand requires impossible |reload in |reload |libffi/src/ia64/ffi.c | Severity|normal |major --- Comment #16 from Eric Botcazou 2012-04-06 06:59:29 UTC --- It is time to do something as GCC 4.7 is quite hampered by this on IA-64.
[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-06 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Summary|sparc64 bootstrap failure: |[4.8 regression] bootstrap |"MASK_LONG_DOUBLE_128" |failure: |redefined |"MASK_LONG_DOUBLE_128" ||redefined Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-04-06 06:37:07 UTC --- > This patch works for Linux/sparc. But it may not work > for all sparc targets which don't include long-double-switch.opt. You can easily find this out, just build a cross to sparc-elf.
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 --- Comment #10 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-04-06 04:52:13 UTC --- I made the warnings on by default. Any opinion on whether I should have made them depend on OPT_Woverflow instead? I guess I thought the warning is slightly different in this case than the case of just a regular numeric literal because the warning might cause the programmer to examine a different type of operator as a solution - say template or raw. Still regtesting.
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857
--- Comment #2 from H.J. Lu 2012-04-06 00:50:50
UTC ---
A small testcase:
[hjl@gnu-6 delta]$ cat testcase.c
extern void get_BID128 (int *);
void
__bid128_div (long long bid_y)
{
int res;
get_BID128 (&res);
}
[hjl@gnu-6 delta]$ gcc -mx32 -maddress-mode=long -g -O testcase.c -c && readelf
-w testcase.o | grep "DW_OP_GNU_regval_type: 4294967295"
<79> DW_AT_GNU_call_site_value: 21 byte block: f5 ff ff ff ff f 25 f4 25
8 ec ff ff ff ff ff ff ff 22 f7 2c (DW_OP_GNU_regval_type: 4294967295 (r-1)
<0x25>; DW_OP_GNU_const_type: <0x25> 8 byte block: ec ff ff ff ff ff ff ff ;
DW_OP_plus; DW_OP_GNU_convert <0x2c>)
[hjl@gnu-6 delta]$
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #1 from Andrew Pinski 2012-04-05 23:34:21 UTC --- I think this is wrong approach to things. Basically you should have instead have an option to automake and friends the support for adding only some flags for non shared libraries. Also using -fPIC instead of -fPIE is always ok. So I doubt there is a really issue here. Since the differences between PIC and PIE comes down to if symbols are overridable. PIC is conservative at optimizing. Also how can you tell the difference between compiling for executable and shared library if you don't supply -fPIC? So adding -aslr is not going to be useful really.
[Bug other/52885] New: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 Bug #: 52885 Summary: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: noloa...@gmail.com When writing makefiles or using automake and friends, its currently not possible to to supply 'generic' set of flags via CFLAGS (or CXXFLAGS) and produce position independent code and utilize layout randomization. For example the following will properly setup makefiles for programs, but not shared objects: $ configure CFLAGS="-Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" Others have also felt the discomfort: http://lists.fedoraproject.org/pipermail/devel-announce/2011-August/000821.html. Please provide a switch that allows us to use position independent code and layout randomization that works on both programs and shared objects. I suggest the switch "-aslr" or "-ASLR".
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #25 from Manuel López-Ibáñez 2012-04-05 22:09:30 UTC --- > Another problem with c99-vla-jump-3.c and similar testcases is that it seems > as > if DejaGNU limits the output (or has a limited size buffer for text) and > decides to stop parsing in the middle of a source line, which breaks the > pruning (and misses several diagnostics that need to be matched). Could this > be > true or am I doing something wrong? PR12096 ?
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #24 from Manuel López-Ibáñez 2012-04-05 22:05:15 UTC --- (In reply to comment #23) > (In reply to comment #22) > > * DejaGNU trims leading whitespace before passing the text to prune. > > So it does. Bizarre. > > set comp_output [string trimleft $comp_output] > > I guess we can just remove the initial space from that prune pattern. > > > The problem is that the default regexp of DejaGNU is: > > > > "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+" > > > > the "+" at the end means that it matches as many lines as possible. > > Yes, but only lines that match the line number followed by the pattern; the > source line shouldn't have its own line number before the pattern. There are a few dg- directives with line number 0. They match everywhere. Another problem with c99-vla-jump-3.c and similar testcases is that it seems as if DejaGNU limits the output (or has a limited size buffer for text) and decides to stop parsing in the middle of a source line, which breaks the pruning (and misses several diagnostics that need to be matched). Could this be true or am I doing something wrong? I am starting to reconsider adding -fno-diagnostics-show-caret everywhere.
[Bug target/52882] ICE in memory_address_length, at config/i386/i386.c:23373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52882 Uros Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Uros Bizjak 2012-04-05 21:53:07 UTC --- Fixed.
[Bug fortran/52884] New: double precision constants promoted to 16 byte by -fdefault-real-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884 Bug #: 52884 Summary: double precision constants promoted to 16 byte by -fdefault-real-8 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: steven.vancoil...@gmail.com Contrary to what the man pages say, double precision constants like '1.d0' get promoted to 16 bytes when using -fdefault-real-8 (without -fdefault-double-8). The man pages at the section of -fdefault-double-8 say however that -fdefault-real-8 does not promote constants like that. Is this an error in the man pages? >From the man pages: -fdefault-double-8 Set the "DOUBLE PRECISION" type to an 8 byte wide type. If -fdefault-real-8 is given, "DOUBLE PRECISION" would instead be promoted to 16 bytes if possible, and -fdefault-double-8 can be used to prevent this. The kind of real constants like "1.d0" will not be changed by -fdefault-real-8 though, so also -fdefault-double-8 does not affect it. Using e.g. the following program: program doubletrouble real*8 x double precision y write(*,*) kind(x), kind(y), kind(1.d0) end Compiling without any options gives '8 8 8' as output. Compiling with -fdefault-real-8 gives '8 16 16', while I expected it to be '8 16 8' based on the documentation. This is with gfortran 4.7.0 on Linux x86_64 (Intel Core i5 M 540)
[Bug target/52882] ICE in memory_address_length, at config/i386/i386.c:23373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52882 --- Comment #2 from uros at gcc dot gnu.org 2012-04-05 21:47:19 UTC --- Author: uros Date: Thu Apr 5 21:47:16 2012 New Revision: 186170 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186170 Log: PR target/52882 * config/i386/i386.c (ix86_decompose_address): Allow VOIDmode CONST_INT operands, zero-extended with AND. testsuite/ChangeLog: PR target/52882 * gcc.target/i386/pr52882.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr52882.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c/52883] New: ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883
Bug #: 52883
Summary: ICE in simplify_const_unary_operation, at
simplify-rtx.c:1464
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r2]$ current-gcc -c -O small.c
small.c: In function 'fn2':
small.c:21:1: internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1464
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r2]$ cat small.c
int a, b, d, e, f, i, j, k, l, m;
unsigned c;
int g[] = { }
, h[0];
int
fn1 () {
return 0;
}
void
fn2 () {
c = 0;
e = 0;
for (;; e = 0)
if (f > j) {
k = fn1 ();
l = (d || k) * b;
m = l * a;
h[0] = m <= i;
} else
i = g[c];
}
[regehr@dyson r2]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186167-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186167-install
--program-prefix=r186167- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120405 (experimental) (GCC)
[Bug target/52882] ICE in memory_address_length, at config/i386/i386.c:23373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52882 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-05 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak 2012-04-05 20:43:51 UTC --- Confirmed, 4.8 regression. Patch in testing: --cut here-- Index: config/i386/i386.c === --- config/i386/i386.c (revision 186169) +++ config/i386/i386.c (working copy) @@ -11510,8 +11510,6 @@ ix86_decompose_address (rtx addr, struct ix86_addr addr = SUBREG_REG (addr); else if (GET_MODE (addr) == DImode) addr = gen_rtx_SUBREG (SImode, addr, 0); - else - return 0; } } --cut here--
[Bug middle-end/52881] [4.8 Regression] ICE due to null pointer deref in cfgloop.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52881 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |middle-end Target Milestone|--- |4.8.0 Summary|ICE due to null pointer |[4.8 Regression] ICE due to |deref |null pointer deref in ||cfgloop.c
[Bug c/52882] New: ICE in memory_address_length, at config/i386/i386.c:23373
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52882
Bug #: 52882
Summary: ICE in memory_address_length, at
config/i386/i386.c:23373
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
[regehr@dyson r1]$ current-gcc -c -O small.c
small.c: In function 'fn3':
small.c:14:1: internal compiler error: in memory_address_length, at
config/i386/i386.c:23373
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r1]$ cat small.c
struct S1 {
int f0;
int f1;
};
int fn1 ();
void fn2 (struct S1);
void
fn3 () {
struct S1 a = { 1, 0 };
if (fn1 ())
fn2 (a);
for (; a.f1;) {
}
}
[regehr@dyson r1]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186167-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186167-install
--program-prefix=r186167- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120405 (experimental) (GCC)
[Bug c/52881] New: ICE due to null pointer deref
ode*)
(tree-optimize.c:422)
==30315==by 0x615A09: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1784)
==30315==by 0x6178CB: cgraph_optimize() (cgraphunit.c:1851)
==30315== Address 0x50 is not stack'd, malloc'd or (recently) free'd
==30315==
small.c: In function 'fn3':
small.c:27:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r3]$ cat small.c
int a, b, c, d, e, f, h, i, j, k, l, m, n, o;
static int g;
int
fn1 () {
for (;; ++f)
if (e)
break;
return 0;
}
unsigned char fn2 ();
void
fn3 () {
lbl_220:
if (j) {
lbl_221:
l = (g || b) <= fn1 ();
for (;;) {
g = 0;
fn2 ();
if (k)
goto lbl_220;
break;
}
if (l)
goto lbl_221;
}
}
unsigned char
fn2 () {
o = d ? 0 : c;
h = m | a % o != n;
return i;
}
[regehr@dyson r3]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186167-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186167-install
--program-prefix=r186167- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120405 (experimental) (GCC)
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 --- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-04-05 19:30:41 UTC --- Created attachment 27103 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27103 Patch including testcases - warn and only when necessary on literal overflow. Pass a flag indicating overflow (or underflow) through the preprocessor and lexer down to the C++ parser. Only if a numeric argument literal operator is found do we finally warn. Otherwise block all warnings for over/under-flow of user-defined literals in the preprocessor and lexer. Waiting for a complete regtest.
[Bug libstdc++/16612] empty basic_strings can't live in shared memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612 j.scheid changed: What|Removed |Added CC||julians37 at googlemail dot ||com --- Comment #34 from j.scheid 2012-04-05 18:45:37 UTC --- For what it's worth, it appears as if I was just bitten by this issue in a slightly different context. I was passing a std::string across a dylib boundary which worked on Apple's gcc 4.2.1 but crashed on Windows (MSVC). Figuring that with MSVC the allocator would use a different heap in each dylib I wrote a custom allocator, and now it worked on MSVC but crashed on gcc on Darwin. I worked out that on Darwin, the custom allocator attempted to release the empty string created in the other dylib. Defining _GLIBCXX_FULLY_DYNAMIC_STRING solved the issue. Anyway, I haven't yet dug deep enough to be certain that this is the same issue, but it very much appears as if this is not only a problem for shared memory but also when two dynamic libraries both link against libstdc++ and exchange std::strings. The one thing that baffles me, though, is why this wasn't a problem before I introduced the custom allocator. Does std::allocator have any safeguards against this?
[Bug c/52880] -Woverride-init emitts unexpected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880 eparis at redhat dot com changed: What|Removed |Added Severity|normal |trivial
[Bug c/52880] New: -Woverride-init emitts unexpected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880
Bug #: 52880
Summary: -Woverride-init emitts unexpected error
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: epa...@redhat.com
struct s1 {
int s1i;
int s1j;
};
struct s2 {
struct s1 s1;
int s2x;
int s2y;
};
int main(void)
{
struct s2 s2 = {
.s1.s1i= 0,
.s2y= 1,
.s2x= 2,
.s1.s1j= 3,
};
return 0;
}
$ gcc -o /tmp/tmp /tmp/tmp.c -Woverride-init
/tmp/tmp.c: In function ‘main’:
/tmp/tmp.c:18:3: warning: initialized field overwritten [-Woverride-init]
/tmp/tmp.c:18:3: warning: (near initialization for ‘s2’) [-Woverride-init]
If you twiddle any of the testcase, it doesn't complain. switching the order
you initialize s2x and s2y causes it to not complain. If you want to get 2
warnings you can declare s1 between s2x and s2y.
I see this on both:
gcc-4.7.0-1.fc17.x86_64
gcc-4.4.6-4.el6.x86_64
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #25 from Oleg Endo 2012-04-05 18:43:50 UTC --- Author: olegendo Date: Thu Apr 5 18:43:45 2012 New Revision: 186169 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186169 Log: PR target/50751 * config/sh/sh.c (sh_find_mov_disp_adjust): Take machine_mode as the first argument instead of mode size. Move displacement calculations to ... (mov_insn_size, max_mov_insn_displacement, mov_insn_alignment_mask): ... these new functions. (disp_adjust): Remove max_mov_disp field. (sh_legitimate_index_p): Use max_mov_insn_displacement and mov_insn_alignment_mask. (sh_address_cost): Use max_mov_insn_displacement. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #15 from Leif Leonhardy 2012-04-05
18:03:31 UTC ---
Just for the record:
Also MPIR 2.1.3, MPIR 2.4.0 and NTL 5.5.2 fail to build, with the same error
message ("error: ‘asm’ operand requires impossible reload").
Work-around for MPIR: Compile with (e.g.) '-O0 -finline-functions
-fschedule-insns', which of course is quite odd.
$ uname -rsm
Linux 2.6.16.46-0.12-default ia64
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0/ia64-Linux-suse/libexec/gcc/ia64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.7.0/src/gcc-4.7.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.22/ia64-Linux-suse-gcc-4.6.2/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.22/ia64-Linux-suse-gcc-4.6.2/bin/ld
--with-gmp=/usr/local/mpir-2.5.1/ia64-Linux-suse-gcc-4.6.2
--with-mpfr=/usr/local/mpfr-3.1.0/ia64-Linux-suse-mpir-2.5.1-gcc-4.6.2
--with-mpc=/usr/local/mpc-0.9/ia64-Linux-suse-mpir-2.5.1-mpfr-3.1.0-gcc-4.6.2
--prefix=/usr/local/gcc-4.7.0/ia64-Linux-suse
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #2 from William J. Schmidt 2012-04-05 17:06:47 UTC --- Opened a bug report as https://www.cs.unipr.it/mantis/view.php?id=353 against PPL.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #23 from Jason Merrill 2012-04-05 17:00:59 UTC --- (In reply to comment #22) > * DejaGNU trims leading whitespace before passing the text to prune. So it does. Bizarre. set comp_output [string trimleft $comp_output] I guess we can just remove the initial space from that prune pattern. > The problem is that the default regexp of DejaGNU is: > > "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+" > > the "+" at the end means that it matches as many lines as possible. Yes, but only lines that match the line number followed by the pattern; the source line shouldn't have its own line number before the pattern. However, if an expected error contains .*, it will typically match both the error message and the source line, so any .* in testcases would need to change to \[^\n\].
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #1 from William J. Schmidt 2012-04-05 16:47:32 UTC --- I verified that the looping occurs inside the PPL library, on a call to ppl_PIP_Problem_is_satisfiable. I used ppl_PIP_Problem_ascii_dump to examine the "pip" variable passed into that routine: external_space_dim: 32 internal_space_dim: 0 input_cs( 38 ) size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 f -RPI_V -RPI -NNC_V -NNC size 33 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 -162 0 -1 0 -9 0 0 0 0 0 0 -1620 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 -162 0 -1 0 -9 0 -1620 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V -RPI -NNC_V -NNC size 33 -1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 6480 0 -162 0 -1 0 -9 0 -1620 0 0 0 0 0 0 162 0 1 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 9 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 8 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 17 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC size 33 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f -RPI_V +RPI -NNC_V -NNC first_pending_constraint: 0 status: PARTIALLY_SATISFIABLE parameters variables( 0 ) initial_context 0 x 0 control_parameters CUTTING_STRATEGY_FIRST PIVOT_ROW_STRATEGY_FIRST big_parameter_dimension: 18446744073709551615 current_solution: BOTTOM It appears we'll need to report this to the PPL folks. I'll get an account over there and point them to this PR.
[Bug rtl-optimization/52838] [x32] missed optimization for pointer return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838 --- Comment #5 from Eric Botcazou 2012-04-05 16:16:41 UTC --- > Can we somehow keep the knowledge that it is a zero-extended 32-bit value? > It is useful for encoding purpose. After combine has run, this seems hard. So the easiest approach might be to disable the combination by tweaking the costs at -Os.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #2 from Daniel Starke 2012-04-05 16:14:19 UTC --- (In reply to comment #1) > Please update this bug with respect to the mailing list discussion that took > place. Can you please add a link to the mailing list discussion you are referring to?
[Bug bootstrap/52878] sparc64 bootstrap failure: "MASK_LONG_DOUBLE_128" redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 --- Comment #1 from H.J. Lu 2012-04-05 16:10:41 UTC --- Created attachment 27102 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27102 A patch This patch works for Linux/sparc. But it may not work for all sparc targets which don't include long-double-switch.opt.
[Bug libfortran/52879] New: Pathological reseeding of PRNG generator genernates poor sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 Bug #: 52879 Summary: Pathological reseeding of PRNG generator genernates poor sequence Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ka...@gcc.gnu.org It is possible to reseed the gfortran's PRNG with sets of seeds that generate poor sequences of random numbers. This problem can to light from the discussion in https://groups.google.com/group/comp.lang.fortran/browse_frm/thread/660c46a52644a8ad?hl=en# Consider the program program foo implicit none character(len=40), parameter :: fmt = '(A,12(I0,1X),A,F10.8)' integer i, seed_size, date(8) integer, allocatable :: new_seed(:) real x call random_seed(size=seed_size) allocate(new_seed(1:seed_size)) do i = 6, 12, 2 call date_and_time(values=date) new_seed = 1 new_seed(1) = i * (sum(date(1:3)) + sum(date(5:8))) call random_seed(put=new_seed) call random_number(x) write(*,fmt) 'seeds = [', new_seed, '], x = ', x call sleep(i) end do print * do i = 6, 12, 2 call date_and_time(values=date) new_seed = 1 new_seed(12) = i * (sum(date(1:3)) + sum(date(5:8))) call random_seed(put=new_seed) call random_number(x) write(*,fmt) 'seeds = [ ', new_seed, '], x = ', x call sleep(i) end do deallocate(new_seed) end program foo With 4.6, 4.7, and trunk, I get troutmask:sgk[239] gfc46 -o bar bar.f90 && ./bar seeds = [15852 1 1 1 1 1 1 1 1 1 1 1 ], x = 0.76322097 seeds = [21200 1 1 1 1 1 1 1 1 1 1 1 ], x = 0.76322097 seeds = [26590 1 1 1 1 1 1 1 1 1 1 1 ], x = 0.76322097 seeds = [31332 1 1 1 1 1 1 1 1 1 1 1 ], x = 0.76322097 seeds = [ 1 1 1 1 1 1 1 1 1 1 1 15744 ], x = 0.76526332 seeds = [ 1 1 1 1 1 1 1 1 1 1 1 21048 ], x = 0.76410544 seeds = [ 1 1 1 1 1 1 1 1 1 1 1 26400 ], x = 0.76371950 seeds = [ 1 1 1 1 1 1 1 1 1 1 1 31812 ], x = 0.76429844 It would seem plausible to an ordinary user that if a single seed value is changed, the generated sequence will (significantly?) change. In the first case above, the sequences are identical while in the second case there appears to be a correlation among the low (high) order bits of the initially generated values. random_seed currently scrambles/unscrambles user specified seeds to hopefully prevent a bad set of seed values. One possible fix would be to XOR the user specified seeds with the default seeds before doing the scrambling. On output, the seeds would be unscrambled and then again XOR'd with the default seeds.
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
--- Comment #13 from H.J. Lu 2012-04-05 15:46:02
UTC ---
We shouldn't copy REG_POINTER from SIGN_EXTEND on target with
POINTERS_EXTEND_UNSIGNED > 0. This patch works for me:
diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 6353126..77a7e66 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -1225,8 +1225,12 @@ reg_scan_mark_refs (rtx x, rtx insn)
{
rtx src = SET_SRC (x);
- while (GET_CODE (src) == SIGN_EXTEND
- || GET_CODE (src) == ZERO_EXTEND
+ while (GET_CODE (src) == ZERO_EXTEND
+ || (GET_CODE (src) == SIGN_EXTEND
+#ifdef POINTERS_EXTEND_UNSIGNED
+ && POINTERS_EXTEND_UNSIGNED <= 0
+#endif
+)
|| GET_CODE (src) == TRUNCATE
|| (GET_CODE (src) == SUBREG && subreg_lowpart_p (src)))
src = XEXP (src, 0);
[Bug bootstrap/52878] New: sparc64 bootstrap failure: "MASK_LONG_DOUBLE_128" redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 Bug #: 52878 Summary: sparc64 bootstrap failure: "MASK_LONG_DOUBLE_128" redefined Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org CC: hjl.to...@gmail.com Host: sparc64-linux-gnu Target: sparc64-linux-gnu Starting with revision: r185882 | hjl | 2012-03-27 17:28:41 +0200 (Tue, 27 Mar 2012) | 11 lines Remove MaskNeeded 2012-03-27 H.J. Lu * opth-gen.awk: Allocated a bit for Mask and InverseMask if it hasn't been allocated. Define a target macro for Mask and InverseMask if it hasn't been defined. Remove MaskExists handling. * doc/options.texi: Remove MaskNeeded. sparc64-linux-gnu (gcc63.fsffrance.org) bootstrap fails with: /home/jamborm/gcc/mine/b-obj/./prev-gcc/g++ -B/home/jamborm/gcc/mine/b-obj/./prev-gcc/ -B/home/jamborm/gcc/mine/inst/sparc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include -I/home/jamborm/gcc/mine/src/libstdc++-v3/libsupc++ -L/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jamborm/gcc/mine/b-obj/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/jamborm/gcc/mine/src/gcc -I/home/jamborm/gcc/mine/src/gcc/. -I/home/jamborm/gcc/mine/src/gcc/../include -I/home/jamborm/gcc/mine/src/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4-64/include -I/opt/cfarm/mpfr-2.4.1-64/include -I/opt/cfarm/mpc-0.8-64/include -I/home/jamborm/gcc/mine/src/gcc/../libdecnumber -I/home/jamborm/gcc/mine/src/gcc/../libdecnumber/dpd -I../libdecnumber /home/jamborm/gcc/mine/src/gcc/lto-wrapper.c -o lto-wrapper.o build/genhooks "Target Hook" \ > tmp-target-hooks-def.h build/genhooks "C Target Hook" \ > tmp-c-target-hooks-def.h /bin/sh /home/jamborm/gcc/mine/src/gcc/../move-if-change tmp-target-hooks-def.h \ target-hooks-def.h /bin/sh /home/jamborm/gcc/mine/src/gcc/../move-if-change tmp-c-target-hooks-def.h \ c-family/c-target-hooks-def.h build/genhooks "Common Target Hook" \ > tmp-common-target-hooks-def.h build/genhooks -d \ /home/jamborm/gcc/mine/src/gcc/doc/tm.texi.in > tmp-tm.texi /bin/sh /home/jamborm/gcc/mine/src/gcc/../move-if-change tmp-common-target-hooks-def.h \ common/common-target-hooks-def.h echo timestamp > s-target-hooks-def-h echo timestamp > s-c-target-hooks-def-h case `echo X|tr X '\101'` in \ A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ esac echo timestamp > s-common-target-hooks-def-h mv tmp2-tm.texi tmp-tm.texi /bin/sh /home/jamborm/gcc/mine/src/gcc/../move-if-change tmp-tm.texi tm.texi In file included from /home/jamborm/gcc/mine/src/gcc/lto-wrapper.c:47:0: ./options.h:3564:0: error: "MASK_LONG_DOUBLE_128" redefined [-Werror] ./options.h:3554:0: note: this is the location of the previous definition if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I . -I /home/jamborm/gcc/mine/src/gcc/doc \ -I /home/jamborm/gcc/mine/src/gcc/doc/include -o doc/gccint.info /home/jamborm/gcc/mine/src/gcc/doc/gccint.texi; \ fi cc1plus: all warnings being treated as errors make[3]: *** [lto-wrapper.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gfdl.pod cpp.pod gcov.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/home/jamborm/gcc/mine/b-obj/gcc'
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
H.J. Lu changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Component|rtl-optimization|target
Ever Confirmed|1 |0
--- Comment #12 from H.J. Lu 2012-04-05 15:21:15
UTC ---
The problem starts with
(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
(sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
(nil))
Reg 64 shouldn't be frame related after sign-extension.
[Bug target/52877] ARC cross-compiler cc1 fails on "x=-1;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52877 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target||arc-elf32 Component|c |target Severity|major |normal
[Bug rtl-optimization/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-05 Component|target |rtl-optimization Ever Confirmed|0 |1 --- Comment #11 from Uros Bizjak 2012-04-05 15:16:30 UTC --- Confirmed as rtl optimization issue.
[Bug c/52877] New: ARC cross-compiler cc1 fails on "x=-1;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52877
Bug #: 52877
Summary: ARC cross-compiler cc1 fails on "x=-1;"
Classification: Unclassified
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wolfgang.thum...@t-systems.com
the exact version of GCC: cc1 --version:
GNU C version 4.2.1 (ARC_2.4) (arc-elf32)
compiled by GNU C version 4.6.3.
the system type: uname -a:
Linux acer 3.2-11.slh.1-aptosid-amd64 #1 SMP PREEMPT Wed Mar 14 00:56:37 UTC
2012 x86_64 GNU/Linux
the options when GCC was configured/built:
configure --prefix=/opt/arc --target=arc-elf32 --with-newlib --with-headers
--enable-multilib --enable-languages=c,c++
(gcc taken from sourceforge as arc_gcc_rel2.4.tar.gz)
the exact command line passed to the gcc program triggering the bug:
./cc1 -o tst.s tst.c
a collection of source files for reproducing the bug:
-- tst.c
int x;
void tst(void){
x=-1;
}
--
a description of the expected behavior:
same bahavior as for "x=1;"
a description of actual behavior:
eval@acer:/tmp$ ./cc1 -o tst.s tst.c
tst
tst.c: In function ‘tst’:
tst.c:5: error: unrecognizable insn:
(insn 7 5 8 3 (set (reg:SI 151)
(const_int -1 [0x])) -1 (nil)
(nil))
tst.c:5: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/52796] [C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52796 Benjamin Kosnik changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #7 from Benjamin Kosnik 2012-04-05 15:06:21 UTC --- Nice work on this Jeffrey.
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #10 from H.J. Lu 2012-04-05 14:30:40 UTC --- simplify_binary_operation (code=AND, mode=DImode, op0=0x71ac0900, op1=0x71a8ffb0) at /export/gnu/import/git/gcc/gcc/simplify-rtx.c:1893 1893 gcc_assert (GET_RTX_CLASS (code) != RTX_COMPARE); (gdb) call debug_rtx (op0) (reg/f:DI 64 [ addr ]) (gdb) call debug_rtx (op1) (const_int 4294967295 [0x]) (gdb) returns (reg/f:DI 64 [ addr ])
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #9 from H.J. Lu 2012-04-05 13:49:31
UTC ---
On trunk, cse1 turns
(insn 6 3 7 2 (set (reg:DI 64)
(sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
(nil))
(insn 7 6 8 2 (parallel [
(set (reg:DI 61 [ li.3 ])
(and:DI (reg:DI 64)
(const_int 4294967295 [0x])))
(clobber (reg:CC 17 flags))
]) x.i:10 377 {*anddi_1}
(nil))
(insn 8 7 9 2 (set (mem/c:DI (symbol_ref:DI ("li")
) [0 li+0 S8 A64])
(reg:DI 61 [ li.3 ])) x.i:10 62 {*movdi_internal_rex64}
(nil))
into
(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
(sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
(nil))
(insn 7 6 8 2 (set (reg:DI 61 [ li.3 ])
(reg/f:DI 64 [ addr ])) x.i:10 62 {*movdi_internal_rex64}
(nil))
(insn 8 7 9 2 (set (mem/c:DI (symbol_ref:DI ("li")
) [0 li+0 S8 A64])
(reg/f:DI 64 [ addr ])) x.i:10 62 {*movdi_internal_rex64}
(nil))
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
--- Comment #8 from H.J. Lu 2012-04-05 13:42:30
UTC ---
The reason why GCC 4.6 works is it uses SImode for Pmode.
On trunk, I got
[hjl@gnu-6 pr52876]$ cat x.i
long long li;
long long testfunc(void* addr) __attribute__ ((noinline));
long long testfunc(void* addr)
{
li = (long long)(int)addr;
// next line is important, if the address from pv
// has been sign extended with leading ONEs
li &= 0x;
return li;
}
[hjl@gnu-6 pr52876]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O x.i
-maddress-mode=long
[hjl@gnu-6 pr52876]$ cat x.s
.file"x.i"
.text
.globltestfunc
.typetestfunc, @function
testfunc:
.LFB0:
.cfi_startproc
movslq%edi, %rax
movq%rax, li(%rip)
ret
.cfi_endproc
.LFE0:
.sizetestfunc, .-testfunc
.commli,8,8
.ident"GCC: (GNU) 4.8.0 20120403 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52876]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O x.i
-maddress-mode=short
[hjl@gnu-6 pr52876]$ cat x.s
.file"x.i"
.text
.globltestfunc
.typetestfunc, @function
testfunc:
.LFB0:
.cfi_startproc
movq%rdi, %rax
movq%rdi, li(%rip)
ret
.cfi_endproc
.LFE0:
.sizetestfunc, .-testfunc
.commli,8,8
.ident"GCC: (GNU) 4.8.0 20120403 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52876]$
-maddress-mode=long generates the wrong code. We have a
POINTERS_EXTEND_UNSIGNED bug.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #18 from Jonathan Wakely 2012-04-05 13:02:53 UTC --- (In reply to comment #17) > I wonder if the problem is that libstdc++ is using both atomics and > pthread_mutex protected manipulation of the same variable? That of course > would fail. I'm pretty sure that can't happen. We always access those variables consistently through a single API, which would always use a mutex or never use a mutex. > Looking at libstdc++ with objdump, I do see quite a few > occurrences of lwarx even though _GLIBCXX_ATOMIC_BUILTINS is undefined. These > are the functions: > > atomic_flag_test_and_set_explicit > _ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception > _ZNSt15__exception_ptr13exception_ptr9_M_addrefEv > _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv > _ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE > _ZL22free_any_cxa_exceptionP17_Unwind_Exception > _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception > __cxa_guard_acquire > __cxa_guard_abort > __cxa_guard_release That looks correct, none of those depends on _GLIBCXX_ATOMIC_BUILTINS Could the problem be the initialization of the function-local static, rather than in locking it later. That initialization should be thread-safe, that's what __cxa_guard_acquire and __cxa_guard_release are used for: http://sourcery.mentor.com/public/cxx-abi/abi.html#once-ctor
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #12 from William J. Schmidt 2012-04-05 12:46:12 UTC --- Forget that last comment. As Richard pointed out on gcc-patches: "That's probably more a C language question - you would get valid C rejected with -fno-common. But maybe -ftree-vectorize should suggest -fno-common when it encounters a case it would like to promote alignment for. Not sure if for example Fortran would ever work with -fno-common though."
[Bug rtl-optimization/52838] [x32] missed optimization for pointer return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838 Uros Bizjak changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #4 from Uros Bizjak 2012-04-05 12:36:28 UTC --- (In reply to comment #2) > The existence of (subreg/s/u:SI (reg:DI 60) 0) means that (reg:DI 60) is known > to be a zero-extended 32-bit value, so the optimization is valid (and useful). Please note similar problem with sign_extend, PR 52876.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 William J. Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from William J. Schmidt 2012-04-05 12:17:06 UTC --- I am closing this as fixed, but the root cause (PR52571) remains open. There is still an open question whether -ftree-vectorize should now imply -fno-common until the latter is no longer needed for the former to be useful.
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #22 from Manuel López-Ibáñez 2012-04-05 12:13:01 UTC --- (In reply to comment #21) > Created attachment 27093 [details] > Patch to prune caret diagnostics from gcc output > > Actually, this seems like a better approach: rather than disable the caret > diagnostics, prune them from the output. This regexp will remove any pair of > lines where the first starts with a space and the second consists of spaces > followed by a caret. Unfortunately this does not work for several reasons: * DejaGNU trims leading whitespace before passing the text to prune. * DejaGNU matches as many lines as possible for each dg-* directive, so if you have something in the source line printed that is matched by a dg-* directive, the line is removed and the above regexp fails to prune the caret line. The problem is that the default regexp of DejaGNU is: "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+" the "+" at the end means that it matches as many lines as possible. It also matches any trailing and any leading whitespace. That is, it is impossible to tell to DejaGNU to match some line exactly.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #10 from William J. Schmidt 2012-04-05 12:11:58 UTC --- Author: wschmidt Date: Thu Apr 5 12:11:50 2012 New Revision: 186163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186163 Log: gcc/testsuite: 2012-04-05 Bill Schmidt Dominique D'Humieures PR testsuite/52614 * gcc.dg/vect/vect.exp: Use -fno-common on all targets. * gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/ppc-costmodel-vect.exp trunk/gcc/testsuite/gcc.dg/vect/vect.exp
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #17 from Alan Modra 2012-04-05 12:05:01 UTC --- I spent quite a bit of time today looking at libpthread and can't spot a problem in pthread_mutex_lock and pthread_mutex_unlock. I wonder if the problem is that libstdc++ is using both atomics and pthread_mutex protected manipulation of the same variable? That of course would fail. Looking at libstdc++ with objdump, I do see quite a few occurrences of lwarx even though _GLIBCXX_ATOMIC_BUILTINS is undefined. These are the functions: atomic_flag_test_and_set_explicit _ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception _ZNSt15__exception_ptr13exception_ptr9_M_addrefEv _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv _ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE _ZL22free_any_cxa_exceptionP17_Unwind_Exception _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception __cxa_guard_acquire __cxa_guard_abort __cxa_guard_release
[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621
Richard Guenther changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #10 from Richard Guenther 2012-04-05
11:27:02 UTC ---
evolution_function_is_univariate_p returns true for
{(integer(kind=8)) {0, +, {2, +, 2}_2}_2, +, 1}_3
but that does not look univariate to me - we do not properly look into
CHREC_LEFT which is (integer(kind=8)) {0, +, {2, +, 2}_2}_2, so something
like
@@ -1114,6 +1132,8 @@ evolution_function_is_univariate_p (cons
break;
default:
+ if (tree_contains_chrecs (CHREC_LEFT (chrec), NULL))
+ return false;
break;
}
@@ -1127,6 +1147,8 @@ evolution_function_is_univariate_p (cons
break;
default:
+ if (tree_contains_chrecs (CHREC_RIGHT (chrec), NULL))
+ return false;
break;
}
fixes this. Then we ICE the same way in analyze_miv_subscript because
we think that beast is affine-multivariate.
The above fix looks obvious to me, but what the right condition for
failing in analyze_overlapping_iterations should be for "loop_nest"
should be, and why using the loop number of the outermost loop of the
nest should be sufficient is beyond my understanding.
Sebastian, can you help? I can certainly amend
/* If they aren't the same, and aren't affine, we can't do anything
yet. */
else if ((chrec_contains_symbols (chrec_a)
|| chrec_contains_symbols (chrec_b))
&& (!evolution_function_is_affine_multivariate_p (chrec_a, lnn)
|| !evolution_function_is_affine_multivariate_p (chrec_b, lnn)))
{
dependence_stats.num_subscript_undetermined++;
*overlap_iterations_a = conflict_fn_not_known ();
*overlap_iterations_b = conflict_fn_not_known ();
}
though it looks to me that this should go into the else part and
the analyze_miv_subscript case lacks a proper test.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4 Summary|[4.6.x/4.7 Regression] |[4.6/4.7/4.8 Regression] |incorrect ln -s replacement |incorrect ln -s replacement |for mingw like targets in |for mingw like targets in |configure files |configure files --- Comment #1 from Richard Guenther 2012-04-05 10:55:03 UTC --- Please update this bug with respect to the mailing list discussion that took place.
[Bug target/50946] [4.6 Regression] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug c++/51214] [4.7/4.8 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.1 Summary|[4.7 Regression] gcc|[4.7/4.8 Regression] gcc |bootstrap with ada fails on |bootstrap with ada fails on |mingw target|mingw target
[Bug c++/52465] [4.7/4.8 regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.1 Summary|[4.7 regression] g++|[4.7/4.8 regression] g++ |rejects valid code with |rejects valid code with |in-class using declaration |in-class using declaration
[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Richard Guenther changed: What|Removed |Added Target||x86_64-*-* Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 Known to fail||4.7.0 --- Comment #9 from Richard Guenther 2012-04-05 10:51:00 UTC --- Confirmed on x86_64-unknown-linux-gnu with -O2 -fprefetch-loop-arrays.
[Bug other/52664] [4.8 Regression]: gcc.dg/tree-ssa/pr31261.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52664 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/52866] [4.8 Regression] build with --enable-libstdcxx-debug fails in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52866 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 Uros Bizjak changed: What|Removed |Added Depends on|52854 |52838 --- Comment #7 from Uros Bizjak 2012-04-05 10:17:37 UTC --- (In reply to comment #6) > This is similar issue as PR 52854, but this time: Oops, PR 52838.
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
Uros Bizjak changed:
What|Removed |Added
Depends on||52854
--- Comment #6 from Uros Bizjak 2012-04-05 10:16:32
UTC ---
This is similar issue as PR 52854, but this time:
(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
(sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) pr52876.c:6
122 {*extendsidi2_rex64}
(expr_list:REG_DEAD (reg/v/f:DI 63 [ addr ])
(nil)))
(insn 7 6 8 2 (parallel [
(set (reg:DI 61 [ li.4 ])
(and:DI (reg/f:DI 64 [ addr ])
(const_int 4294967295 [0x])))
(clobber (reg:CC 17 flags))
]) pr52876.c:10 377 {*anddi_1}
(expr_list:REG_DEAD (reg/f:DI 64 [ addr ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
combine converts this to:
Trying 6 -> 7:
Successfully matched this instruction:
(set (reg:DI 61 [ li.4 ])
(reg/v/f:DI 63 [ addr ]))
(note 6 3 7 2 NOTE_INSN_DELETED)
(insn 7 6 8 2 (set (reg:DI 61 [ li.4 ])
(reg/v/f:DI 63 [ addr ])) pr52876.c:10 62 {*movdi_internal_rex64}
(expr_list:REG_DEAD (reg/v/f:DI 63 [ addr ])
(nil)))
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Rainer Orth 2012-04-05 10:09:46 UTC --- Fixed for 4.8.0.
[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #13 from Rainer Orth 2012-04-05 10:04:50 UTC --- Author: ro Date: Thu Apr 5 10:04:40 2012 New Revision: 186161 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186161 Log: Restore HAVE_INET6 tests (PR libgcj/52645) PR libgcj/52645 * gnu/java/net/natPlainDatagramSocketImplPosix.cc (setOption): Restore HAVE_INET6 check. * gnu/java/net/natPlainDatagramSocketImplWin32.cc (setOption): Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc trunk/libjava/gnu/java/net/natPlainDatagramSocketImplWin32.cc
[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Richard Guenther changed: What|Removed |Added Depends on||52272 Target Milestone|--- |4.7.1 Summary|[4.6/4.7/4.8 Regression]|[4.7/4.8 Regression] 4.6 is |4.6 is faster on Atom |faster on Atom
[Bug bootstrap/52867] Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867 --- Comment #3 from Richard Guenther 2012-04-05 10:03:10 UTC --- Btw, as the ICE happens in the _host_ compiler which is 4.2.x this is even longer unsupported.
[Bug c++/52874] Which directory in gcc contains error or exception message templates?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52874 --- Comment #3 from Andreas Schwab 2012-04-05 09:13:36 UTC --- gcc-h...@gcc.gnu.org and libc-h...@sourceware.org are the mailings list where this kind of question is on-topic.
[Bug fortran/52860] I/O: gfortran rejects writing after hitting END=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52860 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Tobias Burnus 2012-04-05 08:26:57 UTC --- Close as INVALID. >From Fortran 2008, "9.11.3 End-of-file condition and the END= specifier": "If an end-of-file condition occurs during execution of an input/output statement that contains either an END= specifier or an IOSTAT= specifier, and an error condition does not occur then: ... (4) if the file specified in the input statement is an external record file, it is positioned after the endfile record;" And: "9.3.4.3 File position prior to data transfer" "If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file." (Side note: FORTRAN 77 has nearly same words.)
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #5 from Steffen Schmidt 2012-04-05 08:21:38 UTC --- Created attachment 27101 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27101 Assembly -O1 -mx32 gcc 4.6.3 x32 branch
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #4 from Steffen Schmidt 2012-04-05 08:21:03 UTC --- Created attachment 27100 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27100 Assembly -O1 -mx32 gcc 4.7.0
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #3 from Steffen Schmidt 2012-04-05 08:20:23 UTC --- Created attachment 27099 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27099 Assembly -O0
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #2 from Steffen Schmidt 2012-04-05 08:19:49 UTC --- Created attachment 27098 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27098 Example code v3
[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #1 from Steffen Schmidt 2012-04-05 08:19:24 UTC --- Created attachment 27097 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27097 Example code v2
[Bug target/52876] New: [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876
Bug #: 52876
Summary: [x32] - Sign extend 32 to 64bit then clear upper
32bits fails O1 or higher
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: steffen-schm...@siemens.com
Created attachment 27096
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27096
Example code v1
This function sign extends an x32 32bit void* into a 64bit long long global
variable. Afterwards it zeros upper 32bits using binary AND.
long long li;
long long testfunc(void* addr) __attribute__ ((noinline));
long long testfunc(void* addr)
{
li = (long long)(int)addr;
// next line is important, if the address from pv
// has been sign extended with leading ONEs
li &= 0x;
return li;
}
int main (void)
{
volatile long long rv_test;
rv_test = testfunc((void*)0x87651234);
return 0;
}
The following examples are called with parameter (void*)0x87651234
Compiled with gcc 4.7.0 -mx32 -O0 produces:
movq%rdi, %rax
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
cltq #sign extend EAX to RAX, e.g. 0x87651234 to 0x87651234
movq%rax, li(%rip)
movqli(%rip), %rax
andl$4294967295, %eax #the AND 0x, producing 0x87651234
movq%rax, li(%rip)
movqli(%rip), %rax
Compiled with gcc 4.7.0 -mx32 -O1 produces:
movslq%edi, %rax #this is only a sign extend producing 0x87651234
#the zero-ing of the upper 32bits is missing.
movq%rax, li(%rip)
Compiled with gcc 4.6.3 (x32 branch) -mx32 -O1 produces:
movq%rdi, %rax #Here the sign extend and the AND are combined to a mov
#the results in 0x87651234 which is correct.
movq%rdi, li(%rip)
It seems that somehow gcc 4.7.0 "forgets" to clear the upper bits, which gcc
4.6.3 branch x32 did correctly.
The effect only happens in a stand-alone function and using a global variable,
when inlining, the result is correct.
I've attached 3 versions of the test, all failing in O1 or higher. The first
using a global variable, the second a union and a local variable, the third
using a variadic function.
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #6 from Michal Hlavinka 2012-04-05 08:12:54 UTC --- We can see this bug on avr target too. Following code does not work: DirEnttmp = eeFs.files[i_fileId1]; eeFs.files[i_fileId1] = eeFs.files[i_fileId2]; eeFs.files[i_fileId2] = tmp; workaround from comment #4 helps DirEnt tmp; __builtin_memcpy(&tmp, __builtin_assume_aligned(&eeFs.files[i_fileId1], sizeof(DirEnt)), sizeof(DirEnt)); ... ... So it seems it's the same bug
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #16 from Jonathan Wakely 2012-04-05 08:09:53 UTC --- I think we want a macro saying atomics are available for 'int' (which libstdc++ needs for its own uses) and a separate macro saying atomics are available for everything (which is needed for full C++11 support). I've raised it on the libstdc++ list.
[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #15 from Alan Modra 2012-04-05 08:06:30 UTC --- Many hours later one of my 32-bit tests failed, but I'm relieved to say it was only the pthread_once bug. #0 0x0fbd839c in raise () from /lib/power7/libc.so.6 #1 0x0fbda034 in abort () from /lib/power7/libc.so.6 #2 0x0fd9f480 in uw_init_context_1 (context=context@entry=0xf2dce8f8, outer_cfa=outer_cfa@entry=0xf2dcecf0, outer_ra=0xff20f98) at /home/amodra/src/gcc-current/libgcc/unwind-dw2.c:1502 #3 0x0fd9fb7c in _Unwind_RaiseException (exc=0x1002c360) at /home/amodra/src/gcc-current/libgcc/unwind.inc:88 #4 0x0ff20f98 in __cxxabiv1::__cxa_throw (obj=0x1002c380, tinfo=, dest=) at /home/amodra/src/gcc-current/libstdc++-v3/libsupc++/eh_throw.cc:78 #5 0x1d24 in std::tr1::__throw_bad_weak_ptr () at /home/amodra/build/gcc-current/powerpc-linux/libstdc++-v3/include/tr1/shared_ptr.h:76 #6 0x1e9c in _M_add_ref_lock (this=0x10021f60) at /home/amodra/build/gcc-current/powerpc-linux/libstdc++-v3/include/tr1/shared_ptr.h:244 #7 __shared_count (__r=..., this=) at /home/amodra/build/gcc-current/powerpc-linux/libstdc++-v3/include/tr1/shared_ptr.h:494 #8 __shared_ptr (__r=..., this=) at /home/amodra/build/gcc-current/powerpc-linux/libstdc++-v3/include/tr1/shared_ptr.h:586 #9 shared_ptr (__r=..., this=) at /home/amodra/build/gcc-current/powerpc-linux/libstdc++-v3/include/tr1/shared_ptr.h:1015 #10 thread_hammer (opaque_weak=0x1002db44) at /home/amodra/src/gcc-current/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/thread/default_weaktoshared.cc:132 #11 0x0fd5749c in start_thread () from /lib/power7/libpthread.so.0 #12 0x0fc92160 in clone () from /lib/power7/libc.so.6
[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52840 Bernhard Reutner-Fischer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #5 from Bernhard Reutner-Fischer 2012-04-05 07:02:18 UTC --- Fixed on trunk. thanks,
[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52840 --- Comment #4 from Bernhard Reutner-Fischer 2012-04-05 07:00:41 UTC --- Author: aldot Date: Thu Apr 5 07:00:30 2012 New Revision: 186156 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186156 Log: PR bootstrap/52840: libstdc++: let debug find sources for compatibility.lo 2012-04-05 Bernhard Reutner-Fischer PR bootstrap/52840 * src/Makefile.am (build-debug): Do not adjust vpath dir, remove Makefile.tmp * src/Makefile.in: Adjust as per above. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in
