[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #20 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 13:56:05 UTC --- (In reply to comment #17) H.J., I agree with what you write in comment 16. But unless we are sure that the problematic composition will never be generated (e.g. by ivopts), we cannot afford that. I come to a conclusion that we must transform ptr_extend:DI (plus:SI (FOO:SI) (const_int Y))) to (plus:DI (ptr_extend:DI (FOO:SI)) (const_int Y)) since this this how GCC supports Pmode != ptr_mode. You can disable it and watch its fallout on HP-UX. We never run into it for zero_extend before since x32 is the first zero_extend target. We should extend it to zero_extend. The patch in comment 7 may have some snafu, but overall it looks very sane. It's just that a const is not being stripped. Can it be applied on top of the I tried to strip const with diff --git a/gcc/explow.c b/gcc/explow.c index 069a68a..17afbbc 100644 --- a/gcc/explow.c +++ b/gcc/explow.c @@ -380,7 +380,7 @@ convert_memory_address_addr_space_1 (enum machine_mode to_mode ATTRIBUTE_UNUSED, case CONST: temp = convert_memory_address_addr_space_1 (to_mode, XEXP (x, 0), as, no_emit); - return temp ? gen_rtx_CONST (to_mode, temp) : temp; + return temp !REG_P (temp) ? gen_rtx_CONST (to_mode, temp) : temp; break; case PLUS: and it still has massive failures: http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00264.html x32 branch? Or do I first have to revert some earlier revision? The patch in comment 7 is for trunk.
[Bug lto/49922] I try to build libgmp using PGO and lto, but the test will result in internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49922 --- Comment #1 from PcX xunxun1982 at gmail dot com 2011-08-03 14:00:26 UTC --- Change to lto component
[Bug tree-optimization/49957] Fails to SLP in 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-03 14:05:13 UTC --- Cf. RFC Fortran patch at http://gcc.gnu.org/ml/fortran/2011-08/msg00012.html to change the index order into the canonical form.
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2011-08-03 14:05:06 UTC --- (In reply to comment #20) and it still has massive failures: http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00264.html You broke exceptions. Similar problem can be currently seen on alpha, see PR 49688.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #40 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-03 14:07:36 UTC --- Author: hjl Date: Wed Aug 3 14:07:32 2011 New Revision: 177271 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177271 Log: Add testcases for PR target/47744. 2011-08-03 H.J. Lu hongjiu...@intel.com PR target/47744 * gcc.dg/torture/pr47744-1.c: New. * gcc.dg/torture/pr47744-2.c: Likewise. * gcc.dg/torture/pr47744-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47744-1.c trunk/gcc/testsuite/gcc.dg/torture/pr47744-2.c trunk/gcc/testsuite/gcc.dg/torture/pr47744-3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 14:10:25
UTC ---
(In reply to comment #6)
Created attachment 24899 [details]
Proposed patch that exploits addr32.
H.J., can you please test this patch on mx32.
The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.
It failed the testcase for PR 47744, which I just checked in:
[hjl@gnu-33 ilp32-24]$
/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
-std=gnu99
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
function \u2018matmul_i16\u2019:
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
error: insn does not satisfy its constraints:
(insn 146 66 67 4 (set (reg:TI 0 ax)
(mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
[119])
(reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34 60
{*movti_internal_rex64}
(nil))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-33 ilp32-24]$
[Bug fortran/49962] New: internal compiler error when using type-bounded function returning vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962 Summary: internal compiler error when using type-bounded function returning vector Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: wangmianz...@linuxmail.org Created attachment 24903 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24903 a reduced example when compiling reducedcase.f90, a code using type-bounded function returning vector: $ gfortran -o reducedcase reducedcase.f90 reducedcase.f90: In function ‘test’: reducedcase.f90:18:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions. I think this code should be valid according to fortran 2003 standard. Even if it is not valid, I think better error handling would be good. many thanks. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) $ uname -a Linux mianzhi-laptop 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/49962] internal compiler error when using type-bounded function returning vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-03 14:22:47 UTC --- With gfortran 4.6.1 and trunk, the code compiles and gives at run time 1 2 3 but I get the ICE with 4.5.3. So the bug has been fixed, but not backported to 4.5.
[Bug fortran/49962] internal compiler error when using type-bounded function returning vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962 --- Comment #2 from wangmianzhi wangmianzhi1 at linuxmail dot org 2011-08-03 14:24:19 UTC --- On 2011年08月03日 10:23, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962 --- Comment #1 from Dominique d'Humieresdominiq at lps dot ens.fr 2011-08-03 14:22:47 UTC --- With gfortran 4.6.1 and trunk, the code compiles and gives at run time 1 2 3 but I get the ICE with 4.5.3. So the bug has been fixed, but not backported to 4.5. Thank you for your help very much! Mianzhi
[Bug tree-optimization/49963] New: ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963
Summary: ICE: in abs_hwi, at hwint.c:108
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Host: x86-linux-gnu
Target: avr
Build: x86-linux-gnu
Observed this ICE in the test suite for 4.7 trunk r177267 after upgrading from
177070:
gcc.c-torture/execute/divconst-2.c: In function 'std_eqn':
gcc.c-torture/execute/divconst-2.c:20:3: internal compiler error: in abs_hwi,
at hwint.c:108
FAIL: gcc.c-torture/execute/divconst-2.c compilation, -O0 (internal compiler
error)
FAIL: gcc.c-torture/execute/divconst-2.c compilation, -O1 (internal compiler
error)
FAIL: gcc.c-torture/execute/divconst-2.c compilation, -O2 (internal compiler
error)
...
== configure
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto
Thread model: single
gcc version 4.7.0 20110803 (experimental) (GCC)
GNU C (GCC) version 4.7.0 20110803 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
== hwint.c:abs_hwi()
hwint.c:abs_hwi() reads
/* Compute the absolute value of X. */
HOST_WIDE_INT
abs_hwi (HOST_WIDE_INT x)
{
gcc_checking_assert (x != HOST_WIDE_INT_MIN);
return x = 0 ? x : -x;
}
== Backtrace =
#0 fancy_abort (file=0x8890660 ../../../gcc.gnu.org/trunk/gcc/hwint.c,
line=108, function=0x889069b abs_hwi) at
../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893
#1 0x08395087 in abs_hwi (x=-2147483648) at
../../../gcc.gnu.org/trunk/gcc/hwint.c:108
#2 0x08306e8a in fold_plusminus_mult_expr (loc=2983, code=PLUS_EXPR,
type=0xb7d5d420, arg0=0xb7dcdcb0, arg1=0xb7dce24c) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:7040
#3 0x082bbef6 in fold_binary_loc (loc=2983, code=PLUS_EXPR, type=0xb7d5d420,
op0=0xb7dcdcb0, op1=0xb7dce24c) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:9685
#4 0x083174d5 in fold (expr=0xb7dcdccc) at
../../../gcc.gnu.org/trunk/gcc/fold-const.c:13666
#5 0x0813c46c in c_fully_fold_internal (expr=0xb7dcdccc, in_init=0 '\0',
maybe_const_operands=0xbfffdf4b \001\030, maybe_const_itself=0xbfffde6a
\001\001ÌÜÜ· ÔÕ·) at ../../../gcc.gnu.org/trunk/gcc/c-family/c-common.c:1238
#6 0x0813d19b in c_fully_fold (expr=0xb7dcdccc, in_init=212 'Ô',
maybe_const=0xbfffdf4b \001\030) at
../../../gcc.gnu.org/trunk/gcc/c-family/c-common.c:1029
#7 0x080eadcb in build_binary_op (location=2989, code=EQ_EXPR,
orig_op0=0xb7dcdccc, orig_op1=0xb7dce150, convert_p=1) at
../../../gcc.gnu.org/trunk/gcc/c-typeck.c:10172
#8 0x080ef279 in parser_build_binary_op (location=2989, code=EQ_EXPR,
arg1={value = 0xb7dcdccc, original_code = PLUS_EXPR, original_type = 0x0},
arg2={value = 0xb7dce150, original_code = ERROR_MARK, original_type =
0xb7d5d420}) at ../../../gcc.gnu.org/trunk/gcc/c-typeck.c:3218
#9 0x080fbe57 in c_parser_binary_expression (parser=0xb7dcda9c, after=value
optimized out, prec=PREC_NONE) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:5663
#10 0x080fc49f in c_parser_conditional_expression (parser=0xb7dcda9c,
after=0x8000) at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:5330
#11 0x080fc9c8 in c_parser_expr_no_commas (parser=0xb7dcda9c, after=0x8000)
at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:5250
#12 0x080fce68 in c_parser_expression (parser=0xb7d97dd4) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:6716
#13 0x080fe5f3 in c_parser_expression_conv (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:6747
#14 0x080f887a in c_parser_statement_after_labels (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:4416
#15 0x080f997a in c_parser_compound_statement_nostart (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:4147
#16 0x08107852 in c_parser_compound_statement (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:3984
#17 0x080f7fc3 in c_parser_declaration_or_fndef (parser=0xb7dcda9c, fndef_ok=1
'\001', static_assert_ok=value optimized out, empty_ok=1 '\001', nested=0
'\0', start_attr_ok=value optimized out, objc_foreach_object_declaration=0x0)
at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:1749
#18 0x081081da in c_parser_external_declaration (parser=0xb7dcda9c) at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:1354
#19 0x08108a1b in c_parse_file () at
../../../gcc.gnu.org/trunk/gcc/c-parser.c:1242
#20 0x081501b5 in c_common_parse_file () at
../../../gcc.gnu.org/trunk/gcc/c
[Bug bootstrap/49964] New: Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 Summary: Bootstrap failed with AVX turned on Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Revision 177268 failed to bootstrap with AVX enabled.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 --- Comment #1 from Yukhin Kirill kirill.yukhin at intel dot com 2011-08-03 14:28:55 UTC --- Started from here http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00051.html
[Bug tree-optimization/49957] Fails to SLP in 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03 14:41:49 UTC --- The patch now makes us vectorize shell_lam.f:303: note: LOOP VECTORIZED. shell_lam.f:262: note: LOOP VECTORIZED. shell_lam.f:205: note: LOOP VECTORIZED. compared to just shell_lam.f:262: note: LOOP VECTORIZED. without.
[Bug middle-end/47383] [x32] ivopts miscompiles Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383 --- Comment #17 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-03 14:44:59 UTC --- Author: hjl Date: Wed Aug 3 14:44:54 2011 New Revision: 177277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177277 Log: Add a testcase for PR middle-end/47383. 2011-08-03 H.J. Lu hongjiu...@intel.com PR middle-end/47383 * gcc.dg/torture/pr47383.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47383.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
--- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2011-08-03 14:45:40
UTC ---
(In reply to comment #8)
Created attachment 24899 [details]
Proposed patch that exploits addr32.
H.J., can you please test this patch on mx32.
The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu {,-m32}.
It failed the testcase for PR 47744, which I just checked in:
[hjl@gnu-33 ilp32-24]$
/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
-std=gnu99
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
function \u2018matmul_i16\u2019:
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
error: insn does not satisfy its constraints:
(insn 146 66 67 4 (set (reg:TI 0 ax)
(mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
[119])
(reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34 60
{*movti_internal_rex64}
(nil))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-33 ilp32-24]$
Hm, offsetable operand ...
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #22 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 14:48:09 UTC --- (In reply to comment #17) H.J., I agree with what you write in comment 16. But unless we are sure that the problematic composition will never be generated (e.g. by ivopts), we cannot afford that. My understanding is ivopts only works on ptr_mode (see PR 47383).
[Bug rtl-optimization/49900] [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2011-08-03 14:49:56 UTC --- Works on Babe.
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/49740] [4.7 Regression] powerpc native bootstrap with -O3 produces Bootstrap comparison failure!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740 --- Comment #2 from Douglas Mencken dougmencken at gmail dot com 2011-08-03 14:56:23 UTC --- (In reply to comment #1) Did it recover? What shall I try? gcc-4.7-20110730? svn checkout? Some patch? (Nothing has been attached or reported.)
[Bug libgomp/49965] New: libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 Summary: libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Two new libgomp testcases FAIL on Solaris 11/SPARC: FAIL: libgomp.c++/reduction-4.C -O0 execution test both 32 and 64-bit abort () here: #3 0x000183b8 in foolong long, long double () at /vol/gcc/src/hg/trunk/solaris/libgomp/testsuite/libgomp.c++/reduction-4.C:26 j = 8, p = inf This doesn't happen on Solaris 10/x86. FAIL: libgomp.c++/task-8.C -O0 (test for excess errors) Excess errors: ld: warning: symbol 'err' has differing types: (file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC); /var/tmp//ccD0aiQD.o definition taken ld: warning: symbol 'err' has differing types: (file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC); err() was only introduced in Solaris 11. Replacing err by error fixes this.
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2011-08-03 15:01:10
UTC ---
(In reply to comment #9)
(In reply to comment #8)
Created attachment 24899 [details]
Proposed patch that exploits addr32.
H.J., can you please test this patch on mx32.
The patch bootstraps and regression tests OK on x86_64-pc-linux-gnu
{,-m32}.
It failed the testcase for PR 47744, which I just checked in:
[hjl@gnu-33 ilp32-24]$
/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3
-std=gnu99
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c: In
function \u2018matmul_i16\u2019:
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
error: insn does not satisfy its constraints:
(insn 146 66 67 4 (set (reg:TI 0 ax)
(mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:119 ivtmp.30 ]
[119])
(reg:SI 5 di [orig:102 dest_y ] [102]))) [6 MEM[base:
dest_y_18, index: ivtmp.30_63, offset: 0B]+0 S16 A128]))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:34
60
{*movti_internal_rex64}
(nil))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/torture/pr47744-2.c:40:1:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-33 ilp32-24]$
Hm, offsetable operand ...
This additional patch prevents zero_extend when we deal with
wider-than-word-size moves. These moves need offsetable_operand, which
zero_extend (...) isn't.
Index: i386.c
===
--- i386.c(revision 177281)
+++ i386.c(working copy)
@@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_
rtx base, index, disp;
HOST_WIDE_INT scale;
+ if (GET_CODE (addr) == ZERO_EXTEND
+ GET_MODE_SIZE (mode) UNITS_PER_WORD)
+ return false;
+
if (ix86_decompose_address (addr, parts) = 0)
/* Decomposition failed. */
return false;
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org |
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 15:10:13 UTC --- for task-8.C, error is a function on linux, so please replace it by errval or err_atomic or similar instead if err doesn't work on Solaris. Fur reduction-4.C, perhaps Solaris long double handling is broken? The testcase doesn't use anything complicated, in *.omp_fn* of the long long/long double version the private f is initialized to +Inf, then in some iterations set to 9.0 or -2.0 and finally everything is MIN_EXPRed together in a critical section.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #102 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-08-03 15:12:29 UTC --- --- Comment #101 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-03 10:02:44 UTC --- Thanks Marc. Thus, it seems to me that Rainer should have a look to the fixincludes, double check make sense to him, aren't library bits and should be sorted out between you two. What would help enormously for this would be a complete justification for the individual fixes: * Does a standard call for some specific declaration? If so, which one, chapter and verse? In such a case, it will be easier get Oracle's attention so the issue is also fixed upstream.(If only C++ 2011, it might be a bit of a tougher ride.) * If this is a libstdc++ requirement not currently demanded by a standard, would there be an alternative way to fix this inside libstdc++? The reason I'm asking is that the OS headers tend to be a moving target, and you may have to keep updating the fix to keep it working. Please keep in mind that my understanding of C++ is minimal, so what may be obvious to you might not be to me. I'm not at all opposed to perform fixincludes fixes, but if there are alternatives, they should at least be considered. Thanks. Rainer
[Bug tree-optimization/49955] Fails to do partial basic-block SLP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.08.03 15:12:42 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03 15:12:42 UTC --- The loop that remains after fixing PR49957 in 410.bwaves is the following, which loop SLP does not handle (well, I'm not exactly sure) because t.f:18: note: == examining statement: t1_62 = *q_61(D)[D.1645_60]; t.f:18: note: num. args = 4 (not unary/binary/ternary op). t.f:18: note: vect_is_simple_use: operand *q_61(D)[D.1645_60] t.f:18: note: not ssa-name. t.f:18: note: use not simple. t.f:18: note: no array mode for V2DF[5] t.f:18: note: the size of the group of strided accesses is not a power of 2 t.f:18: note: not vectorized: relevant stmt not supported: t1_62 = *q_61(D)[D.1645_60]; t.f:18: note: bad operation or unsupported loop bound. t.f:1: note: vectorized 0 loops in function. probably the issue that we can't handle this kind of invariants in the SLP group? Thus, the SLP group should be q(2,..), q(3,...) ... q(5, ...) which is size 4, q(1,..) should be treated as invariant. subroutine shell(nx,ny,nz,q,dt,cfl,dx,dy,dz) implicit none integer nx,ny,nz,n,i,j,k real*8 cfl,dx,dy,dz,dt real*8 gm,Re,Pr,cfll,t1,t2,t3,t4,t5,t6,t7,t8,mu real*8 q(5,nx,ny,nz) C This particular problem is periodic only cfll=0.1d0+(n-1.0d0)*cfl/20.0d0 if (cfll.ge.cfl) cfll=cfl t8=0.0d0 do k=1,nz do j=1,ny do i=1,nx t1=q(1,i,j,k) t2=q(2,i,j,k)/t1 t3=q(3,i,j,k)/t1 t4=q(4,i,j,k)/t1 t5=(gm-1.0d0)*(q(5,i,j,k)-0.5d0*t1*(t2*t2+t3*t3+t4*t4)) t6=dSQRT(gm*t5/t1) mu=gm*Pr*(gm*t5/t1)**0.75d0*2.0d0/Re/t1 t7=((dabs(t2)+t6)/dx+mu/dx**2)**2 + 1((dabs(t3)+t6)/dy+mu/dy**2)**2 + 2((dabs(t4)+t6)/dz+mu/dz**2)**2 t7=DSQRT(t7) t8=max(t8,t7) enddo enddo enddo dt=cfll / t8 return end
[Bug tree-optimization/49957] Fails to SLP in 410.bwaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49957 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03 15:17:42 UTC --- Mine.
[Bug fortran/49961] type bounded function can not return a pointer of a array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49961 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-03 15:21:32 UTC --- Thanks for the report. As it is not a regression, I don't think the fix will be back-ported. Fortunately, it seems to be fixed in 4.6.x and in the current developer version 4.7. For using OOP programming features such as type-bound procedures and polymorphism, it is best to use GCC 4.6 or 4.7. See http://gcc.gnu.org/wiki/OOP for an overview of fixed and still unfixed OOP bugs by GCC version. Maybe Ubuntu also has a newer version, which can be installed besides (or instead of) the system GCC. If not, Debian has GCC 4.6.1 in Testing/Unstable, cf. http://packages.debian.org/search?keywords=gfortransearchon=namessuite=allsection=all Additionally, unofficial nightly builds of GCC are available from http://gcc.gnu.org/wiki/GFortranBinaries Those can also be installed without root permissions in some directory.
[Bug fortran/49962] internal compiler error when using type-bounded function returning vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49962 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-03 15:21:23 UTC --- Thanks for the report. As it is not a regression, I don't think the fix will be back-ported. Fortunately, it seems to be fixed in 4.6.x and in the current developer version 4.7. For using OOP programming features such as type-bound procedures and polymorphism, it is best to use GCC 4.6 or 4.7. See http://gcc.gnu.org/wiki/OOP for an overview of fixed and still unfixed OOP bugs by GCC version. Maybe Ubuntu also has a newer version, which can be installed besides (or instead of) the system GCC. If not, Debian has GCC 4.6.1 in Testing/Unstable, cf. http://packages.debian.org/search?keywords=gfortransearchon=namessuite=allsection=all Additionally, unofficial nightly builds of GCC are available from http://gcc.gnu.org/wiki/GFortranBinaries Those can also be installed without root permissions in some directory.
[Bug middle-end/49946] Thread jumps confuse loop unrolling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49946 --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com 2011-08-03 15:26:57 UTC --- Used compiler: Target: x86_64-unknown-linux-gnu Thread model: posix gcc version 4.7.0 20110802 (experimental) (GCC)
[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.08.03 15:26:26 CC||paolo.carlini at oracle dot ||com, rth at gcc dot ||gnu.org, spop at gcc dot ||gnu.org Target Milestone|--- |4.7.0 Summary|ICE: in abs_hwi, at |[4.7 Regression] ICE: in |hwint.c:108 |abs_hwi, at hwint.c:108 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03 15:26:26 UTC --- Well - as I said. Here we go. Please fix :P
[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03 15:27:36 UTC --- Probably fails on any 32bit HWI platform.
[Bug c/49966] New: gcc.c-torture/execute/pr45034.c execution timeouts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966 Summary: gcc.c-torture/execute/pr45034.c execution timeouts Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu At r177224 as well as in current gcc trunk, the gcc.c-torture/execute/pr45034.c execution tests are timing out on x86_64-apple-darwin11 at -m32 and -m64... WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O2 WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O3 -fomit-frame-pointer WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O3 -fomit-frame-pointer -funroll-loops WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O3 -g WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -Os WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O2 -flto -flto-partition=none WARNING: program timed out. FAIL: gcc.c-torture/execute/pr45034.c execution, -O2 -flto
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #12 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-08-03 15:29:50 UTC --- (In reply to comment #11) Did you use an absolute path for the source dir? There have been problems with relative paths in the past. Tried absolute path with 4.6.1, and compilation finishes alright. cd /home/htl10/tmp-build tar jxpvf ../sources/www.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.6.1/gcc-4.6.1.tar.bz2 mkdir gcc-461-obj cd gcc-461-obj CONFIG_SHELL=/usr/local/bin/bash /home/htl10/tmp-build/gcc-4.6.1/configure CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make --- I am running make -k check at the moment but will retry 4.5.3/4.6.0 afterwards. Note that 4.4.6 fails even with absolute path at a later place. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947#c14) So I can probably say this bug was fixed with 4.6.1.
[Bug c/49966] gcc.c-torture/execute/pr45034.c execution timeouts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-08-03 15:31:28 UTC --- Created attachment 24904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24904 preprocessed source file for gcc.c-torture/execute/pr45034.c on x86_64-apple-darwin11 Generated with... /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/ /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110803/gcc/testsuite/gcc.c-torture/execute/pr45034.c -w -O2 -lm -m32 -o /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/pr45034.x2 --save-temps
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added Known to work||4.6.1 --- Comment #13 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-08-03 15:32:31 UTC --- adding 4.6.1 known to work. pending retrying 4.5.3/4.6.0
[Bug c/49966] gcc.c-torture/execute/pr45034.c execution timeouts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49966 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-08-03 15:32:57 UTC --- Created attachment 24905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24905 assembly file for gcc.c-torture/execute/pr45034.c on x86_64-apple-darwin11 at -O2 Created with... /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/ /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110803/gcc/testsuite/gcc.c-torture/execute/pr45034.c -w -O2 -lm -m32 -o /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/pr45034.x2 --save-temps
[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
Hin-Tak Leung htl10 at users dot sourceforge.net changed:
What|Removed |Added
Known to work||4.6.1
--- Comment #16 from Hin-Tak Leung htl10 at users dot sourceforge.net
2011-08-03 15:38:30 UTC ---
(In reply to comment #15)
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
What I do see is that if you add some -W option to ld, you get exactly
the message you observe. E.g.
That's stating the obvious... it is essentially what the error message is
complaining ('flags must be ordered in some way)
Do you happen to have some environment variable set to -Wsomething?
Though I have found no hint that ld would check for this, it's a
possibility.
No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
full/relative path related.
[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-08-03 15:42:46 UTC ---
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after
-_SYSTYPE_SVR4
What I do see is that if you add some -W option to ld, you get exactly
the message you observe. E.g.
That's stating the obvious... it is essentially what the error message is
complaining ('flags must be ordered in some way)
Not really: there's no documented -_SYSTYPE_SVR4 flag, and ld doesn't
accept such a flag at all. The error message is sort of nonsensical.
Do you happen to have some environment variable set to -Wsomething?
Though I have found no hint that ld would check for this, it's a
possibility.
No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
full/relative path related.
Still really strange: I've never seen such a ld message before, building
gcc or otherwise.
Anyway, great that it works for you now.
Rainer
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 15:44:59 UTC --- (In reply to comment #10) This additional patch prevents zero_extend when we deal with wider-than-word-size moves. These moves need offsetable_operand, which zero_extend (...) isn't. Index: i386.c === --- i386.c(revision 177281) +++ i386.c(working copy) @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_ rtx base, index, disp; HOST_WIDE_INT scale; + if (GET_CODE (addr) == ZERO_EXTEND + GET_MODE_SIZE (mode) UNITS_PER_WORD) + return false; + if (ix86_decompose_address (addr, parts) = 0) /* Decomposition failed. */ return false; gcc.dg/torture/pr47744-2.c compiled with -mx32 -O3 -std=gnu99 -ftree-vectorize -funroll-loops generates codes like leal(%rax,%r9), %r12d leal(%rax,%rdi), %r10d mov%r12d, %edx movq(%r12d), %rbp movq8(%rdx), %rdx movq(%r12d), %rax Many leal aren't necessary.
[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-03 15:45:06 UTC --- Eh, my way of fixing it would be removing the assert ;) Seriously, too bad, I can try to look a bit into it but help is welcome of course, I don't think the project wants to rely on my judgment about this vs 49914...
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #103 from Marc Glisse marc.glisse at normalesup dot org 2011-08-03 15:52:09 UTC --- (In reply to comment #102) What would help enormously for this would be a complete justification for the individual fixes: Of course. I tried to keep the fixincludes to the minimum. One fixes the issue with getc/getchar explained above. One removes the extern C++ overloads of bsearch/qsort because of PR 2316 : Solaris is right to have those, but most compilers (wrongly) don't consider linkage (C vs C++) as part of the type and thus to them Solaris is defining the same function twice. One wraps the declarations of pow(*,int) with #ifdef so that they remain available in C++03 (Solaris is right to have them, section 26.5.6 of the standard) but they disappear in C++0X (to match section 26.8.9 of N3291). The first 2 are necessary. I believe the last one is not required (it should just cause one minor bug in C++0X) and can be reconsidered later if you prefer. I haven't tested the version of the fixinclude patch attached to the bug, I was going to do that once I get access to a Solaris 10 (we have one, but it takes a while to register so I can use it). I wrote the patch on S11, so I also wanted to get a look at the S10 headers to check for differences. In such a case, it will be easier get Oracle's attention so the issue is also fixed upstream.(If only C++ 2011, it might be a bit of a tougher ride.) I guess Oracle will implement C++2011 at some point, no need to push them. The libstdc++ headers will need adjusting when that happens. The getc issue is worth reporting upstream though. * If this is a libstdc++ requirement not currently demanded by a standard, would there be an alternative way to fix this inside libstdc++? The reason I'm asking is that the OS headers tend to be a moving target, and you may have to keep updating the fix to keep it working. I completely agree with this, but it looks hard without fixinclude. Note that I am not a fixinclude expert and it is possible the fixes could be written in a less fragile way. And I think one c_fix_arg is supposed to be select instead.
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781 --- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2011-08-03 16:08:47 UTC --- (In reply to comment #11) gcc.dg/torture/pr47744-2.c compiled with -mx32 -O3 -std=gnu99 -ftree-vectorize -funroll-loops generates codes like leal(%rax,%r9), %r12d leal(%rax,%rdi), %r10d mov%r12d, %edx movq(%r12d), %rbp movq8(%rdx), %rdx movq(%r12d), %rax Many leal aren't necessary. This is the tradeof for using offsetable address for DWI operands.
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 16:18:45 UTC --- (In reply to comment #10) This additional patch prevents zero_extend when we deal with wider-than-word-size moves. These moves need offsetable_operand, which zero_extend (...) isn't. Index: i386.c === --- i386.c(revision 177281) +++ i386.c(working copy) @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_ rtx base, index, disp; HOST_WIDE_INT scale; + if (GET_CODE (addr) == ZERO_EXTEND + GET_MODE_SIZE (mode) UNITS_PER_WORD) + return false; + if (ix86_decompose_address (addr, parts) = 0) /* Decomposition failed. */ return false; Doesn't work. I got FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error) FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors) FAIL: libgomp.fortran/omp_parse4.f90 -Os (internal compiler error) FAIL: libgomp.fortran/omp_parse4.f90 -Os (test for excess errors) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (internal compiler error) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (test for excess errors) so far: spawn -ignore SIGHUP /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c -O2 -fgraphite-identity -fdump-tree-graphite-all -S -mx32 -o pr35356-2.s^M /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c: In function 'foo':^M /export/gnu/import/git/gcc-x32/gcc/testsuite/gcc.dg/graphite/pr35356-2.c:17:1: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #2 from Ilker R Capoglu begovic79 at gmail dot com 2011-08-03 16:20:53 UTC --- (In reply to comment #1) An attachment is missing. Please try to create a small self-contained testcase using complex. Sorry, I think it didn't get uploaded because it was above 1000k. I'll try and get a smaller .ii file. Thanks!
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-08-03 16:26:45 UTC --- --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 15:10:13 UTC --- for task-8.C, error is a function on linux, so please replace it by errval or err_atomic or similar instead if err doesn't work on Solaris. Sure: I'd have tested that on Linux/x86_64 before submitting anyway. Fur reduction-4.C, perhaps Solaris long double handling is broken? The Not in general :-) testcase doesn't use anything complicated, in *.omp_fn* of the long long/long double version the private f is initialized to +Inf, then in some iterations set to 9.0 or -2.0 and finally everything is MIN_EXPRed together in a critical section. What I've done is adding a couple of printf's all over template typename I, typename F void foo (): before the #pragma omp parallel for, before and after each assignement in the for loop, and before and after the abort, every time casting the args to long long resp. long double with matching format strings. It I initialize i to 0 before the #pragma so I get comparable output, there's no difference in output between i386-pc-solaris2.10 and sparc-sun-solaris2.11 except for the abort. Rainer
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-03 16:27:23 UTC --- http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful if you can't reduce it then using gzip or bzip2 might make it small enough to attach
[Bug target/49950] GOT relocation for -fPIE is excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49950 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 16:29:48 UTC --- default_binds_local_p_1 has: /* Uninitialized COMMON variable may be unified with symbols resolved from other modules. */ else if (DECL_COMMON (exp) !resolved_locally (DECL_INITIAL (exp) == NULL || DECL_INITIAL (exp) == error_mark_node)) local_p = false; Now, it depends on what the callers expect. If they want to figure out if the decl can't be interposed by other library etc., then the above lines are unnecessary, but if it wants to find out e.g. if it can trust DECL_INITIAL or lack thereof of the DECL etc., then the above is needed. E.g. we use targetm.binds_local_p to find out if anchoring should be used, for commons it certainly shouldn't be.
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #4 from Ilker R Capoglu begovic79 at gmail dot com 2011-08-03 16:32:47 UTC --- (In reply to comment #3) http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful if you can't reduce it then using gzip or bzip2 might make it small enough to attach I actually read the instructions very carefully and managed to go through a lot of it. The problem is that (a) I'm not so familiar with the internals of the blitz++ library to prune out the crud effectively (b) the STL headers are buried so deep into blitz++ that it takes a blitz++ developer to take them out. I'll try to gzip the file and resubmit, though.
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #5 from Ilker R Capoglu begovic79 at gmail dot com 2011-08-03 16:34:31 UTC --- Created attachment 24906 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24906 The preprocessed file with the STL and blitz++ headers. (bzip2'd)
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 16:37:36 UTC --- So what values it printed? Did it print -2.0 and 9.0 in some iterations? The final merging is done in a critical section between GOMP_atomic_start and GOMP_atomic_end, perhaps you can put a breakpoint in there and watch how the values are merged using the MIN_EXPR. Can you reproduce the failure with OMP_NUM_THREADS=1 BTW?
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 16:47:09 UTC --- Created attachment 24907 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24907 A testcase [hjl@gnu-33 delta]$ /export/build/gnu/gcc-x32-test/release/usr/gcc-4.7.0-x32/bin/gcc -mx32 -std=gnu99 -fgnu89-inline -O2-S testcase.c testcase.c:634:2: 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.
[Bug c++/49967] New: The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967 Summary: The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others) Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@cyberscience.com Host: HP-UX IA64 Target: HP-UX IA64 The -static-libstdc++ option is silently ignored on HP-IX, IA64 platform. The reason for this seems to be that g++spec.c relies on HAVE_LD_STATIC_DYNAMIC from auto-host.h, and if this is not set silently fails to implement -static-libstdc++. The HP linker does have options to implement HAVE_LD_STATIC_DYNAMIC, but configure has not detected them. Presumably this is because they are not the usual -Bstatic and -Bdynamic, the HP options are -aarchive and -ashared_archive (not -ashared which disables archive libs completely). Changing auto-host.h to use: #define HAVE_LD_STATIC_DYNAMIC 1 #define LD_DYNAMIC_OPTION -ashared_archive #define LD_STATIC_OPTION -aarchive resolves the issue, but of course is not the right fix since this file is generated. So, this is really a configuration time issue. As an additional fix though, I would really expect g++ to error or warn if -static-libstdc++ can't be implemented, instead of silently ignoring. Also it could provide the archive name to the linker in place of -lstdc++ for systems where HAVE_LD_STATIC_DYNAMIC really doesn't exist - but possibly if this were fixed for HP there might not be any systems with this restriction.
[Bug target/49781] [x32] Unnecessary lea in x32 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 16:49:12 UTC --- (In reply to comment #13) (In reply to comment #10) This additional patch prevents zero_extend when we deal with wider-than-word-size moves. These moves need offsetable_operand, which zero_extend (...) isn't. Index: i386.c === --- i386.c(revision 177281) +++ i386.c(working copy) @@ -11681,6 +11689,10 @@ ix86_legitimate_address_p (enum machine_ rtx base, index, disp; HOST_WIDE_INT scale; + if (GET_CODE (addr) == ZERO_EXTEND + GET_MODE_SIZE (mode) UNITS_PER_WORD) + return false; + if (ix86_decompose_address (addr, parts) = 0) /* Decomposition failed. */ return false; Doesn't work. I got FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error) FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors) FAIL: libgomp.fortran/omp_parse4.f90 -Os (internal compiler error) FAIL: libgomp.fortran/omp_parse4.f90 -Os (test for excess errors) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (internal compiler error) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (test for excess errors) Total regressions: FAIL: gcc.c-torture/compile/2717-1.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/2717-1.c -Os (test for excess errors) FAIL: gcc.c-torture/execute/builtins/strcat.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/unsorted/xdi.c, -O1 (internal compiler error) FAIL: gcc.dg/graphite/pr35356-2.c (internal compiler error) FAIL: gcc.dg/graphite/pr35356-2.c (test for excess errors) FAIL: gcc.dg/torture/pr45636.c -O1 (internal compiler error) FAIL: gcc.dg/torture/pr45636.c -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O1 (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O2 (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -Os (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -Os (test for excess errors) FAIL: gfortran.dg/bounds_check_array_ctor_1.f90 -O1 (internal compiler error) FAIL: gfortran.dg/bounds_check_array_ctor_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/bounds_check_array_ctor_6.f90 -O1 (internal compiler error) FAIL: gfortran.dg/bounds_check_array_ctor_6.f90 -O1 (test for excess errors) FAIL: gfortran.dg/bounds_check_array_ctor_8.f90 -O1 (internal compiler error) FAIL: gfortran.dg/bounds_check_array_ctor_8.f90 -O1 (test for excess errors) FAIL: gfortran.dg/character_array_constructor_1.f90 -O1 (internal compiler error) FAIL: gfortran.dg/character_array_constructor_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/char_expr_3.f90 -O1 (internal compiler error) FAIL: gfortran.dg/char_expr_3.f90 -O1 (test for excess errors) FAIL: gfortran.dg/char_length_3.f90 -O (internal compiler error) FAIL: gfortran.dg/char_length_3.f90 -O (test for excess errors) FAIL: gfortran.dg/extends_1.f03 -O1 (internal compiler error) FAIL: gfortran.dg/extends_1.f03 -O1 (test for excess errors) FAIL: gfortran.dg/g77/7388.f -O1 (internal compiler error) FAIL: gfortran.dg/g77/7388.f -O1 (test for excess errors) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (internal compiler error) FAIL: gfortran.dg/gomp/crayptr5.f90 -O (test for excess errors) FAIL: gfortran.dg/namelist_66.f90 -O2 (internal compiler error) FAIL: gfortran.dg/namelist_66.f90 -O2 (test for excess errors) FAIL: gfortran.dg/proc_ptr_22.f90 -O2 (internal compiler error) FAIL: gfortran.dg/proc_ptr_22.f90 -O2 (test for excess errors) FAIL: gfortran.dg/proc_ptr_22.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/proc_ptr_22.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/proc_ptr_22.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/proc_ptr_22.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O2 (internal compiler error) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O2 (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -g (test for excess errors) FAIL: gfortran.fortran-torture/execute/where_11.f90, -Os (internal compiler error) FAIL: gfortran.fortran-torture/execute/where_2.f90, -Os (internal compiler error) FAIL: libgomp.fortran/omp_parse4.f90 -Os (internal compiler error) FAIL: libgomp.fortran/omp_parse4.f90 -Os (test for excess errors)
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-08-03 16:50:27 UTC --- --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 16:37:36 UTC --- So what values it printed? Did it print -2.0 and 9.0 in some iterations? Here's the complete output: i = 0: j = -1, f = 1024 i = 1: f = Inf i = 2: j = -2147483648, f = Inf i = 1: f = -2 i = 2: j = 8, f = Inf i = 3 i = 2: j = 8, f = 9 i = 0: j = -2147483648 i = 0: j = -16 i = 0: j = 8, f = -2 i = 0: j = -1, f = 1024 i = 1: f = Inf i = 1: f = -2 i = 3 i = 2: j = -2147483648, f = Inf i = 2: j = 8, f = Inf i = 2: j = 8, f = 9 i = 0: j = -2147483648 i = 0: j = -16 i = 0: j = 8, f = -2 i = 0: j = -1, f = 1024 i = 1: f = Inf i = 1: f = -2 i = 3 i = 2: j = -9223372036854775808, f = Inf i = 2: j = 8, f = Inf i = 2: j = 8, f = 9 i = 0: j = -9223372036854775808 i = 0: j = -16 i = 0: j = 8, f = Inf The final merging is done in a critical section between GOMP_atomic_start and GOMP_atomic_end, perhaps you can put a breakpoint in there and watch how the values are merged using the MIN_EXPR. I've missed the right call so far. Will give it another try tomorrow. Can you reproduce the failure with OMP_NUM_THREADS=1 BTW? Yes, the failure is the same, just with i = 0: j = -1, f = 1024 i = 0: j = -9223372036854775808 i = 0: j = -16 i = 1: f = Inf i = 1: f = -2 i = 2: j = -16, f = -2 i = 2: j = 8, f = -2 i = 2: j = 8, f = -2 i = 3 i = 0: j = 8, f = 1024 Abort Rainer
[Bug web/49935] Upgrade GCC Bugzilla to 3.6.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49935 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.08.03 16:54:20 AssignedTo|unassigned at gcc dot |LpSolit at netscape dot net |gnu.org | Ever Confirmed|0 |1
[Bug middle-end/49968] New: ICE in calls.c:3141 / assert after emit_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49968 Summary: ICE in calls.c:3141 / assert after emit_stack_restore Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: uweig...@gcc.gnu.org CC: r...@gcc.gnu.org Target: spu-elf I'm seeing ICEs in calls.c:3141 on spu-elf after this patch went in: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00075.html One test case showing this problem is: gcc.c-torture/compile/20030224-1.c The problem here is that SPU's restore_stack_block generates insn sequences that do not terminate in a SET of stack_pointer_rtx, see this for further discussion: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00326.html
[Bug middle-end/49968] ICE in calls.c:3141 / assert after emit_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49968 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.08.03 17:18:39 AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 17:18:39 UTC --- Mine.
[Bug middle-end/49969] New: not vectorized: data ref analysis failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49969 Summary: not vectorized: data ref analysis failed Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: i...@gcc.gnu.org, rguent...@suse.de The following program does not vectorize. With Intel's ifort one gets the message: PERMUTED LOOP WAS VECTORIZED while GCC just prints: test.f90:6: note: not vectorized: data ref analysis failed D.1566_33 = *iz_32(D)[D.1565_31]; test.f90:7: note: not vectorized: data ref analysis failed D.1566_33 = *iz_32(D)[D.1565_31]; test.f90:2: note: vectorized 0 loops in function. In case of GCC, it does not depend on the loop order - permuting does not change anything. Also it is independent of the patch to PR 49957. ! From Polyhedron's ac.f90, line 746 SUBROUTINE SUSCEP(L,Iz,Dsus) INTEGER L , Iz(L,L) , iznum DOUBLE PRECISION Dsus iznum = 0 DO iy = 1 , L DO ix = 1 , L iznum = iznum + Iz(iy,ix) ENDDO ENDDO Dsus = DBLE(iznum) Dsus = Dsus*Dsus Dsus = Dsus/(L*L) END
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.08.03 17:37:53 CC||rth at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 17:37:53 UTC --- It is caused by revision 177218: http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00228.html On Linux/ia32, adding -march=corei7-avx caused: [hjl@gnu-snb-1 src]$ /export/gnu/import/rrs-bootstrap/177218/bld/./gcc/xgcc -shared-libgcc -B/export/gnu/import/rrs-bootstrap/177218/bld/./gcc -nostdinc++ -L/export/gnu/import/rrs-bootstrap/177218/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/gnu/import/rrs-bootstrap/177218/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/gnu/import/rrs-bootstrap/177218/usr/x86_64-unknown-linux-gnu/bin/ -B/export/gnu/import/rrs-bootstrap/177218/usr/x86_64-unknown-linux-gnu/lib/ -isystem /export/gnu/import/rrs-bootstrap/177218/usr/x86_64-unknown-linux-gnu/include -isystem /export/gnu/import/rrs-bootstrap/177218/usr/x86_64-unknown-linux-gnu/sys-include -m32 -I/export/gnu/import/rrs-bootstrap/177218/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/gnu/import/rrs-bootstrap/177218/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/export/gnu/import/rrs-bootstrap/177218/src/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=functexcept.lo -g -O2 -D_GNU_SOURCE -m32 -std=gnu++0x -c ../../../../../src/libstdc++-v3/src/functexcept.cc -fPIC -DPIC -S -march=corei7-avx ../../../../../src/libstdc++-v3/src/functexcept.cc: In function ‘void std::__throw_system_error(int)’: ../../../../../src/libstdc++-v3/src/functexcept.cc:106:62: internal compiler error: in fixup_args_size_notes, at expr.c:3586 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-snb-1 src]$
[Bug c/49923] __attirubte__((packed)) on ARM is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2011-08-03 17:39:05 UTC --- Søren, can you please verify this patch fixes the problem for you? It's based on trunk but should apply well to the 4.6 branch too. Thanks. Index: src/gcc/tree-sra.c === --- src.orig/gcc/tree-sra.c +++ src/gcc/tree-sra.c @@ -3688,6 +3688,9 @@ access_precludes_ipa_sra_p (struct acces || gimple_code (access-stmt) == GIMPLE_ASM)) return true; + if (tree_non_mode_aligned_mem_p (access-expr)) +return true; + return false; }
[Bug libfortran/49970] New: make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
Summary: make prefix=... install doesn't work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ji...@gmx.net
On a multilib x86_64 config, I tried doing make prefix=$HOME/mydir install.
Installation failed in directory x86_64-unknown-linux-gnu/32/libgfortran/
because it tried writing to some dir under /usr/local. Looking into the
generated Makefile in that path I can see that the default prefix, /usr/local,
was hardcoded in several points.
Shouldn't it be ${prefix} instead of /usr/local?
[Bug middle-end/49968] ICE in calls.c:3141 / assert after emit_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49968 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 18:00:21 UTC --- Created attachment 24908 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24908 proposed patch I believe this will solve the problem.
[Bug middle-end/49968] ICE in calls.c:3141 / assert after emit_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49968 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 18:02:43 UTC --- Mine.
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638 --- Comment #4 from janus at gcc dot gnu.org 2011-08-03 18:36:55 UTC --- (In reply to comment #3) A check for different ranks can be added like this: This will reject the following variant of the original test case, which is accepted up to now: module world implicit none type :: world_1 contains procedure, nopass :: string = w1_string end type type, extends(world_1)::world_2 contains procedure, nopass :: string = w2_string end type contains function w1_string() integer :: w1_string w1_string = 1 end function function w2_string() integer,dimension(2) ::w2_string w2_string = 2 end function end module program hello use world implicit none type(world_1)::w1 type(world_2)::w2 print *,hello world: hello,w1%string() print *,hello world2: hello,w2%string() end program
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-08-03 18:49:11 UTC --- Why do you think that this will work? No where on http://gcc.gnu.org/install/ is the form make prefix=... documented. If you want to install gcc into a directory other than /usr/local, then use 'path_to_gcc_src/configure --prefix=where_gcc_will_live'.
[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: address taken, but ADDRESSABLE bit not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 18:49:43 UTC --- Author: jakub Date: Wed Aug 3 18:49:40 2011 New Revision: 177291 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177291 Log: PR tree-optimization/49948 * gimple.c (walk_stmt_load_store_addr_ops): Walk CONSTRUCTOR elements. * gcc.dg/pr49948.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49948.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.08.03 18:52:08 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|Various non-conforming |[DR 1214] Various |behaviors with |non-conforming behaviors |braced-init-list|with braced-init-list |initialization |initialization Ever Confirmed|0 |1
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638 --- Comment #5 from janus at gcc dot gnu.org 2011-08-03 18:53:17 UTC --- I think in general we may also have to reject differing non-constant string lengths (at least that's what ifort does), as in: module world implicit none type :: world_1 contains procedure, nopass :: string = w1_string end type type, extends(world_1) :: world_2 contains procedure, nopass :: string = w2_string end type contains function w1_string(x) integer, intent(in) :: x character(2*x) :: w1_string w1_string = world end function function w2_string(x) integer, intent(in) :: x character(3*x) :: w2_string w2_string = world2 end function end module program hello use world implicit none type(world_1)::w1 type(world_2)::w2 print *,hello world: hello ,w1%string(3),! print *,hello world2: hello ,w2%string(3),! end program
[Bug tree-optimization/49948] ICE with -ftree-parallelize-loops: address taken, but ADDRESSABLE bit not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-03 18:56:05 UTC --- Author: jakub Date: Wed Aug 3 18:56:02 2011 New Revision: 177292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177292 Log: PR tree-optimization/49948 * gimple.c (walk_stmt_load_store_addr_ops): Walk CONSTRUCTOR elements. * gcc.dg/pr49948.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49948.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/gimple.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-03 18:59:33 UTC --- I think this is a case for a function absu_hwi or similar that returns an unsigned HOST_WIDE_INT value. (Actually it's a case for operating properly on the INTEGER_CSTs or on double_ints without being conditional on whether the values pass host_integerp, but that's a more complicated fix.)
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #2 from jimis jimis at gmx dot net 2011-08-03 19:01:51 UTC ---
I use it casually for packages that use autotools to configure the build, it
always works fine. And for gcc it has worked for me plenty of times for i386
C-frontend only builds, and till not I've only seen libgfortran failing.
Why it should be supported? Especially for GCC it is very handy, I build the
beast without configuring --prefix at all, and then install someplace. Then I
apply some patch, hit make and only relevant files are compiled, and install
some place elsewhere. If I had to reconfigure with a different --prefix, make
would build many more files, and I'd have to delete various config.cache files
because I reconfigured.
Quote from automake manual:
All these directory variables have values that start with either ‘${prefix}’ or
‘${exec_prefix}’ unexpanded. This works fine in Makefiles, but it makes these
variables hard to use in configure. This is mandated by the GNU coding
standards, so that the user can run ‘make prefix=/foo install’. The Autoconf
manual has a section with more details on this topic (see Installation
Directory Variables). See also Hard-Coded Install Paths.
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-03 19:03:24 UTC --- This is a bug in libtool. See bug 46607. It will need to be fixed in upstream libtool (see bug 46607 comment 10 for what might be the simplest approach).
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-03 19:09:22 UTC --- On Wed, Aug 03, 2011 at 07:01:55PM +, jimis at gmx dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 --- Comment #2 from jimis jimis at gmx dot net 2011-08-03 19:01:51 UTC --- I use it casually for packages that use autotools to configure the build, it always works fine. And for gcc it has worked for me plenty of times for i386 C-frontend only builds, and till not I've only seen libgfortran failing. Why it should be supported? Especially for GCC it is very handy, I build the beast without configuring --prefix at all, and then install someplace. Then I apply some patch, hit make and only relevant files are compiled, and install some place elsewhere. If I had to reconfigure with a different --prefix, make would build many more files, and I'd have to delete various config.cache files because I reconfigured. Have you actually read the instead instructions for gcc? Have you tried the documented method [*]: make DESTDIR=path-to-rootdir install [*] I don't know if it works. If it fails, then you have bug to report.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964
--- Comment #4 from Richard Henderson rth at gcc dot gnu.org 2011-08-03
19:11:48 UTC ---
It's a bug in the i386 backend:
(call_insn 28 27 136 2 (parallel [
(parallel [
(call (mem:QI (mem/f:SI (plus:SI (reg/f:SI 73 [
__ec$_M_cat_2-_vptr.error_category ])
(const_int 12 [0xc])) [3 MEM[(int
(*__vtbl_ptr_type) () *)D.126512_12 + 12B]+0 S4 A32]) [0
*OBJ_TYPE_REF(D.126513_13;__ec$_M_cat_2-3) S1 A8])
(const_int 12 [0xc]))
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
])
(unspec [
(const_int 2 [0x2])
] UNSPEC_CALL_NEEDS_VZEROUPPER)
])
/home/rth/work/gcc/bld/i686-linux/libstdc++-v3/include/system_error:158 480
{*call_pop_vzeroupper}
Note the nested PARALLEL.
[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #7 from Johannes Schaub schaub.johannes at googlemail dot com
2011-08-03 19:17:04 UTC ---
(In reply to comment #6)
You can define it as follows to make it work in both cases
#define PTHREAD_COND_INITIALIZER {}
I cannot define/redefine this value. It's already defined in system headers...
Ah I wasn't aware. You can at least workaround it though.
class cond_variable
{
struct { ::pthread_cond_t cond; } wrapper;
public:
constexpr cond_variable() : wrapper{PTHREAD_COND_INITIALIZER} {}
};
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 --- Comment #5 from jimis jimis at gmx dot net 2011-08-03 19:32:09 UTC --- DESTDIR is supported just fine, but it is not prefix, it serves different purposes. In particular it installs in /$DESTDIR/$prefix but installed package would search libraries in /$prefix. joseph: Thanks for pointing me to that bug, hopefully this will be fixed in libtool, it's much needed functionality at least for me.
[Bug target/43746] -fmerge-constants and -fmerge-all-constants don't work at AVR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||schlie at comcast dot net --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-03 19:40:32 UTC --- *** Bug 21018 has been marked as a duplicate of this bug. ***
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Priority|P2 |P3
CC||gjl at gcc dot gnu.org
Resolution|WONTFIX |DUPLICATE
Severity|normal |enhancement
--- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-03
19:40:32 UTC ---
Setting this as duplicate; not because it's a real duplicate -- the original
message is rather confusing and I can't really depict what it's intention is --
but because the contributors to this PR might be also interestet in PR43746
which touches similar topic like duplicate strings and string merging on AVR
that is addressed here, too.
(In reply to comment #0)
char s[5] = abcde;
char t[5] = {'a','b','c','d','e'};
Note that abcde is a string literal containing 6 chars (only 5 are copied)
and the second initializer has length 5 bytes and is not a string.
resulting tree/rtl:
showing frame-relative reference to abcde initializing data which is wrong:
(set (reg:HI 44)
(symbol_ref/f:HI (*.LC0) [flags 0x2] string_cst 0x160b840))
Note that the /f flag has different meanings depending on where it is attached
to, see http://gcc.gnu.org/viewcvs/trunk/gcc/rtl.h?view=markup
(In reply to comment #6)
Now, if that macro is called with identical string literals within one
translation unit, the strings are allocated separately rather than merged
into a single location.
This behaviour is reproducable as well on the i386 target, so it looks like
not really related to the avr backend.
[...]
#define PROGMEM __attribute__((__progmem__))
#define PSTR(x) \
(__extension__({static const char __c[] PROGMEM = (x); __c[0];}))
extern void puts_P(const char *);
void dosomething(void)
{
puts_P(PSTR(Hello world!));
puts_P(PSTR(Hello world!));
}
Compiling for the avr target yields:
[...]
.section.progmem.data,a,@progbits
.type __c.1473, @object
.size __c.1473, 13
__c.1473:
.string Hello world!
.type __c.1471, @object
.size __c.1471, 13
__c.1471:
.string Hello world!
Compiling the same file for the i386 target also shows two copies of the
string literal: [...]
Problem is not the duplicate string literals it's the missing section flags
like aMS for mergeable strings and binutils would take care of this.
This is rooted in the way avr backend up to now implements progem attribute,
i.e. is simply bangs a section .progmem against a decl without caring for the
kind of data. This is not hard to change, but it has to be implemented.
For constants in .rodata string merging was achieved wihout effort by cleaning
up the avr backend. Notice that .rodata is still in RAM but named .rodata now
and not mapped to .data as in = 4.6.
*** This bug has been marked as a duplicate of bug 43746 ***
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638
--- Comment #6 from janus at gcc dot gnu.org 2011-08-03 19:41:17 UTC ---
The simple constant-length example in comment #0 can be rejected by extending
the resolve.c part of the patch in comment #3 into:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 177065)
+++ gcc/fortran/resolve.c(working copy)
@@ -10760,13 +10760,28 @@ check_typebound_override (gfc_symtree* proc, gfc_s
/* FIXME: Do more comprehensive checking (including, for instance, the
rank and array-shape). */
gcc_assert (proc_target-result old_target-result);
- if (!gfc_compare_types (proc_target-result-ts,
- old_target-result-ts))
+ if (!compare_type_rank (proc_target-result, old_target-result))
{
gfc_error ('%s' at %L and the overridden FUNCTION should have
- matching result types, proc-name, where);
+ matching result types and ranks, proc-name, where);
return FAILURE;
}
+
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl proc_target-result-ts.u.cl-length
+ proc_target-result-ts.u.cl-length-expr_type == EXPR_CONSTANT
+ old_target-result-ts.u.cl old_target-result-ts.u.cl
old_target-result-ts.u.cl-length
+ old_target-result-ts.u.cl-length-expr_type == EXPR_CONSTANT
+ (mpz_cmp (proc_target-result-ts.u.cl-length-value.integer,
+ old_target-result-ts.u.cl-length-value.integer) != 0))
+{
+ gfc_error (Character length mismatch (%ld/%ld) between '%s' at '%L'
+ and overridden FUNCTION,
+ mpz_get_si (proc_target-ts.u.cl-length-value.integer),
+ mpz_get_si (old_target-ts.u.cl-length-value.integer),
+ proc-name, where);
+ return FAILURE;
+}
}
/* If the overridden binding is PUBLIC, the overriding one must not be
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-03 19:57:06 UTC --- Hmm, we should never make the cgrpah point to inline variant in this case, so rest of compilation should go smoothly after the error is output. I don't think it is what is confusing ipa-pta, especially now when it is run after inlining? Honza
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-03 20:00:22 UTC --- Hmm, it looks like recursive_inlining_p predicate broke with presence of aliases. I will take a look.
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-03 20:01:15 UTC --- Mine, BTW
[Bug middle-end/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-03 20:11:16 UTC --- It seems that I never submitted the patch. It is posted now. Honza
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
Andrew Paprocki andrew at ishiboo dot com changed:
What|Removed |Added
CC||andrew at ishiboo dot com
--- Comment #104 from Andrew Paprocki andrew at ishiboo dot com 2011-08-03
20:17:26 UTC ---
Wow, just got bit by this 10 year old bug on Solaris 10. The following code
correctly errors with Sun's compiler:
#include string.h
int main() { char* foo = strchr(z, 'z'); return 0; }
foo.c, line 2: Error: Cannot assign const char* to char*.
But under no invocation of g++ does this even print a warning (-Wall -Wextra
-Wcast-qual) because Solaris iso/string_iso.h only declares the return value
'const' when __cplusplus = 199711L.
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638
--- Comment #7 from janus at gcc dot gnu.org 2011-08-03 20:17:49 UTC ---
I wonder whether the right thing to do would be to add a general expression
comparison routine like the one below (just a rough sketch so far).
a) Do we have something like this already? I found gfc_compare_expr in arith.c,
but this does not seem to do quite what we need here (e.g. it only handles
constant expressions, etc).
b) Is it overkill and things can be done in a simpler way?
===
--- gcc/fortran/expr.c(revision 177065)
+++ gcc/fortran/expr.c(working copy)
@@ -255,6 +255,80 @@ gfc_get_iokind_expr (locus *where, io_kind k)
}
+/* Compare two expressions. */
+
+gfc_try
+gfc_cmp_expr (gfc_expr *e1, gfc_expr *e2)
+{
+ if (e1 == NULL e2 == NULL)
+return SUCCESS;
+
+ if (e1-expr_type != e2-expr_type)
+return FAILURE;
+
+ switch (e1-expr_type)
+{
+case EXPR_CONSTANT:
+ switch (e1-ts.type)
+{
+case BT_INTEGER:
+ if (mpz_cmp (e1-value.integer, e2-value.integer) != 0)
+return FAILURE;
+ break;
+
+case BT_REAL:
+ if (mpfr_cmp (e1-value.real, e2-value.real) != 0)
+return FAILURE;
+ break;
+
+case BT_COMPLEX:
+ if (mpc_cmp (e1-value.complex, e2-value.complex) != 0)
+return FAILURE;
+ break;
+
+case BT_CHARACTER: /* TODO. */
+case BT_HOLLERITH:
+case BT_LOGICAL:
+case BT_DERIVED:
+case BT_CLASS:
+ break;
+
+case BT_PROCEDURE:
+case BT_VOID:
+ /* Should never be reached. */
+case BT_UNKNOWN:
+ gfc_internal_error (gfc_copy_expr(): Bad expr node);
+ /* Not reached. */
+}
+ break;
+
+case EXPR_VARIABLE:
+ if (strcmp (e1-symtree-n.sym-name, e1-symtree-n.sym-name) != 0)
+return FAILURE;
+
+case EXPR_OP:
+ if (e1-value.op.op != e2-value.op.op)
+return FAILURE;
+ if (gfc_cmp_expr (e1-value.op.op1, e2-value.op.op1) == FAILURE)
+return FAILURE;
+ if (gfc_cmp_expr (e1-value.op.op2, e2-value.op.op2) == FAILURE)
+return FAILURE;
+ break;
+
+case EXPR_FUNCTION: /* TODO. */
+case EXPR_ARRAY:
+case EXPR_SUBSTRING:
+case EXPR_COMPCALL:
+case EXPR_PPC:
+case EXPR_STRUCTURE:
+case EXPR_NULL:
+ break;
+}
+
+ return SUCCESS;
+}
+
+
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #105 from Andrew Paprocki andrew at ishiboo dot com 2011-08-03
20:26:17 UTC ---
$ uname -a
SunOS sun 5.10 Generic_137111-08 sun4v sparc SUNW,T5240 Solaris
$ CC -V
CC: Sun C++ 5.10 SunOS_sparc 128228-10 2010/08/18
$ g++ -dumpversion
4.5.2
$ cat foo.cpp
#include string.h
int main() { char* foo = strchr(z, 'z'); return 0; }
$ CC -c foo.cpp
foo.cpp, line 2: Error: Cannot use const char* to initialize char*.
1 Error(s) detected.
$ g++ -std=c++0x -pedantic -Wall -Wextra -Wno-unused -c foo.cpp
$
[Bug tree-optimization/49963] [4.7 Regression] ICE: in abs_hwi, at hwint.c:108
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-03 20:29:51 UTC --- Created attachment 24909 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24909 Draft patch I'm attaching a patch which tries to implement what Joseph suggests (thanks!). Essentially, I'm replacing all uses of abs_hwi outside hwint.c itself, besides three in tree-ssa-math-opts.c which seem correct anyway: the argument is an HOST_WIDE_INT / 2 or / 3 and the result is passed to a function taking a plain HOST_WIDE_INT. Type-wise the patch makes a lot of sense to me. Maybe submitter could test it? I'm sanity checking it on x86_64.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 20:51:22 UTC --- Created attachment 24910 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24910 A patch I am testing this.
[Bug c/49923] __attirubte__((packed)) on ARM is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923 --- Comment #6 from Søren Holm sgh at sgh dot dk 2011-08-03 21:00:06 UTC --- As far as my isolated test-case goes the patch works. :D I will report back after a test on the target tomorrow.
[Bug middle-end/49968] ICE in calls.c:3141 / assert after emit_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49968 --- Comment #3 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-08-03 21:21:32 UTC --- The patch did indeed fix the testcase, thanks! Running a full regression now ...
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org 2011-08-03 21:35:49 UTC --- (In reply to comment #7) I wonder whether the right thing to do would be to add a general expression comparison routine like the one below (just a rough sketch so far). a) Do we have something like this already? I found gfc_compare_expr in arith.c, but this does not seem to do quite what we need here (e.g. it only handles constant expressions, etc). b) Is it overkill and things can be done in a simpler way? 4.5.7.3 (type-bound procedure overriding) has: • Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3). 12.3.3 (Characteristics of function results): If a type parameter of a function result or a bound of a function result array is not a constant expression, the exact dependence on the entities in the expression is a characteristic So the standards asks for same-expression-ness. Whether a compiler should diagnose it is another question. I understand reversed operands (for commutative operators) as having an equal exact dependence on the entities. And same for associative operators. Thus it is bound to be very complicated in the general case. However one could use an exact expression comparison (like what you proposed) and emit a warning only. This should take care of the most common cases without being too complicated. About the functions to reuse there is also gfc_dep_compare_expr and its sub-functions (they should handle functions, variables and arithmetic operators). I don't know however how you will have two corresponding dummy arguments (from different procedures) compare equal. It's possibly not that simple after all, if you need to rewrite the functions. As far as I'm concerned, constants are enough then.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Attachment #24910|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | --- Comment #6 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 21:43:53 UTC --- Created attachment 24911 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24911 full patch Your patch misses several patterns. This bootstraps, but I don't have an avx cpu locally.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-08-03 21:46:22 UTC --- (In reply to comment #6) Created attachment 24911 [details] full patch Your patch misses several patterns. This bootstraps, but I don't have an avx cpu locally. I am testing it now. Thanks.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #106 from Marc Glisse marc.glisse at normalesup dot org 2011-08-03 21:51:53 UTC --- (In reply to comment #96) I could trace this to g++ defining __STRICT_ANSI__ for -std=c++98/c++0x. sys/feature_tests.h defines _STRICT_STDC in this case, which hides the !_REENTRANT !_LP64 !_STRICT_STDC getc definition in iso/stdio_iso.h. If you don't like fixincludes, we could also make g++ never define __STRICT_ANSI__ on Solaris. After all, it already unconditionally defines __STDC_VERSION__=199901L, _XOPEN_SOURCE=600 and __EXTENSIONS__...
[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841 --- Comment #6 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-08-03 22:26:13 UTC --- (In reply to comment #5) Please follow the directions I gave in that PR. Start with a standard configure; make setup, no bootstrap-lean4, no relative paths to the source dir. This works just fine for me, so instead of insisting on trying untested paths, first determine if the regular one works. Even gcc 4.5 is old by now... Okay... did the plain configure and make and no relative path, and watching my 4.6.1 make -k check - I'll be summiting the result later to the testsuite mailing list; but it is currently spilling a lot of Unaligned access pid=353493 a.28.1.exe va=0x14000ad5e pc=0x3ff81006d00 ra=0x3ff81006c44 inst=0xb3e9 --- messages, with a different ?.exe. and I looked, and it is currently doing make check inside libgomp . So it looks like there was some kind of alignment regression after 4.4.5 .
[Bug target/34888] Stack patterns for AVR not optimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34888 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 22:57:25 UTC --- Author: rth Date: Wed Aug 3 22:57:22 2011 New Revision: 177300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177300 Log: PR target/34888 * config/avr/avr.md: New splitter for REG_ARGS_SIZE 0. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug target/34888] Stack patterns for AVR not optimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34888 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from Richard Henderson rth at gcc dot gnu.org 2011-08-03 22:58:20 UTC --- Fixed?
[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added Known to work||4.4.5, 4.6.1 Known to fail||4.4.6 --- Comment #7 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-08-03 23:08:47 UTC --- Please ignore last comment 6. With 4.6.1: === libgomp Summary === # of expected passes2586 # of unsupported tests3 So the problem is not seen in 4.6.1.
[Bug bootstrap/49964] Bootstrap failed with AVX turned on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-08-04 00:18:27 UTC --- (In reply to comment #6) Created attachment 24911 [details] full patch Your patch misses several patterns. This bootstraps, but I don't have an avx cpu locally. It works: http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00355.html
