[Bug libstdc++/33628] unary_function and pointer_to_unary_function issues with void template arguments
--- Comment #3 from pcarlini at suse dot de 2008-03-09 11:21 --- I agree ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33628
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #8 from ubizjak at gmail dot com 2008-03-09 11:39 ---
Patch in testing:
Index: i386.c
===
--- i386.c (revision 133051)
+++ i386.c (working copy)
@@ -16789,7 +16789,8 @@
int
ix86_constant_alignment (tree exp, int align)
{
- if (TREE_CODE (exp) == REAL_CST)
+ if (TREE_CODE (exp) == REAL_CST || TREE_CODE (exp) == VECTOR_CST
+ || TREE_CODE (exp) == INTEGER_CST)
{
if (TYPE_MODE (TREE_TYPE (exp)) == DFmode align 64)
return 64;
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-03-08 18:16:11 |2008-03-09 11:39:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words
--- Comment #2 from hutchinsonandy at aim dot com 2008-03-09 12:23 ---
Here is more info:
Testcase:
static long foo99(long b,long a)
{
return b * a;
}
long foo2(long b, long a)
{
return foo99(b,a);
}
Looking at RTL, the USE of the respective libcalls are reversed. That is the
RTL generated for call to MULSI3 is reversed from a normal C function that has
same arguments and calling conventions.
(call_insn/u 9 8 10 920625-1.c:45 (set (reg:SI 22 r22)
(call (mem:HI (symbol_ref:HI (__mulsi3) [flags 0x41]) [0 S2 A8])
(const_int 0 [0x0]))) -1 (expr_list:REG_EH_REGION (const_int -1
[0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:SI 18 r18))
(expr_list:REG_DEP_TRUE (use (reg:SI 22 r22))
(nil
(call_insn/u 9 8 10 920625-1.c:51 (set (reg:SI 22 r22)
(call (mem:HI (symbol_ref:HI (foo99) [flags 0x3] function_decl
0x7fdcf030 foo99) [0 S2 A8])
(const_int 0 [0x0]))) -1 (expr_list:REG_EH_REGION (const_int 0
[0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:SI 22 r22))
(expr_list:REG_DEP_TRUE (use (reg:SI 18 r18))
(nil
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-09 13:33 --- Hmm, we indeed cannot communicate to the backend (or register allocator) that function arguments of a libcall are communtative. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #9 from uros at gcc dot gnu dot org 2008-03-09 13:38 --- Subject: Bug 35496 Author: uros Date: Sun Mar 9 13:37:52 2008 New Revision: 133052 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133052 Log: PR target/35496 * config/i386/i386.c (ix86_constant_algnment): Compute alignment using ALIGN_MODE_128 for VECTOR_CST and INTEGER_CST in addition to REAL_CST. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #10 from hjl dot tools at gmail dot com 2008-03-09 14:06 --- Can we add a few testcases for Linux/ia32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug libgcj/35253] reflection on annotation objects throws IllegalAccessException
--- Comment #2 from marcus at better dot se 2008-03-09 14:46 --- BTW this bug makes TestNG fail horribly with gcj, it relies heavily on reflection with annotations of this kind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35253
[Bug tree-optimization/35513] New: Improve targetm.binds_local_p
Compiler wants to know: 1. If a symbol will be referenced locally within the file. If a readonly symbol with initializer is referenced with the file, compiler may replace symbol read with its initializer. PRs 35402/35494/35501. 2. If a symbol will be referenced locally within the module, an optimized relocation may be used, depend on symbol types. But for weak, undefined, hidden function symbol, it is necessary to treat it as global for read. PR 32219. 3. If a function will be called with in the module, an optimized relocation may be used. However, the current targetm.binds_local_p doesn't distinguish those different usages. As the result, gcc makes wrong conclusions in some cases, PR 32219. I think targetm.binds_local_p should take a parameter to indicate its usage. -- Summary: Improve targetm.binds_local_p Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com OtherBugsDependingO 32219,35402,35494,35501 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35513
[Bug tree-optimization/35513] Improve targetm.binds_local_p
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-09 15:16 --- We can add a parameter to indicate for read, write and branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35513
[Bug target/26149] libgomp.c/ordered-2.c fails on x86-64-linux-gnu with -m32
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-03-09 15:42 --- Still fails in 4.2.x: http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00510.html http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00457.html I don't see the error with the 4.3 branch: http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00669.html Maybe it was fixed and just needs backporting? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org GCC target triplet|x86-64-linux-gnu|x86_64-linux-gnu Known to fail||4.2.0 4.2.4 Known to work||4.3.0 Last reconfirmed|2006-09-03 20:50:37 |2008-03-09 15:42:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-03-09 15:51 --- Created an attachment (id=15284) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15284action=view) make nested iterator typedefs private in debug mode It's accepts implementation-defined not accepts invalid - and it's obviously by design that GCC accepts its own implementation-defined constructs! This patch makes the typedefs inaccessible in debug mode and fixes up a couple of functions that refer to them directly, rather than through iterator_traits. Tested x86_64/linux. I also tried testing with -D_GLIBCXX_DEBUG added to testsuite_flags but got lots of spurious failures that I don't think are related to this change (as with parallel mode testing, all the 23_containers/*/synopsis.cc tests fail in debug mode - I haven't investigated why) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug target/35514] New: Gcc shoud generate symbol type for undefined symbol
Gcc doesn't generate symbol types for undefined symbol on ELF targets:
bash-3.2$ cat x.c
extern void foo() __attribute__((weak,visibility(hidden)));
extern int puts( char const* );
int main()
{
foo ? foo() : puts( foo == null, skipped. );
return 0;
}
bash-3.2$ gcc -c x.c
bash-3.2$ readelf -s x.o
Symbol table '.symtab' contains 12 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS x.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 SECTION LOCAL DEFAULT5
6: 0 SECTION LOCAL DEFAULT6
7: 0 SECTION LOCAL DEFAULT9
8: 0 SECTION LOCAL DEFAULT8
9: 43 FUNCGLOBAL DEFAULT1 main
10: 0 NOTYPE WEAK DEFAULT UND foo
11: 0 NOTYPE GLOBAL DEFAULT UND puts
bash-3.2$
ELF linker needs symbol type to properly issue diagnostic message.
--
Summary: Gcc shoud generate symbol type for undefined symbol
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #8 from jwakely dot gcc at gmail dot com 2008-03-09 15:52 --- Created an attachment (id=15285) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15285action=view) new test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug target/26149] libgomp.c/ordered-2.c fails on x86_64-linux-gnu with -m32
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-03-09 16:07 --- On 4.3.x, this failure goes away sometime on 20070322. Luckily we had two testsuite results on the same day hours apart from one person in which the failure disappears. :-) http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01067.html http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01071.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug target/26149] libgomp.c/ordered-2.c fails on x86_64-linux-gnu with -m32
--- Comment #5 from ubizjak at gmail dot com 2008-03-09 16:17 --- IIRC, this is a testsuite issue, -march=i486 is not appended automatically to compile flags. This was fixed by following patch series: 2007-04-07 John David Anglin [EMAIL PROTECTED] PR testsuite/31369 * testsuite/libgomp.c++/c++.exp: Don't use concat when setting ld_library_path. * testsuite/libgomp.fortran/fortran.exp: Likewise. 2007-03-23 Andreas Tobler [EMAIL PROTECTED] * testsuite/lib/libgomp.exp (libgomp_init): Add -shared-libgcc for *-*-darwin*. * testsuite/libgomp.c++/c++.exp: Look for shared libstdc++ library and use it if found. 2007-03-18 Uros Bizjak [EMAIL PROTECTED] * testsuite/config/default.exp: New file. * testsuite/lib/libgomp.exp: New file. * testsuite/lib/libgomp.dg (load_gcc_lib, libgomp_init, libgomp_target_compile, libgomp_option_help, libgomp_option_proc, load_lib *, load_gcc_lib *): Move to libgomp.exp. (libgomp_load): Remove. * testsuite/lib/libgomp.exp (libgomp_init): Compute always_ld_library_path, not ld_library_path. Set additional_flags to -march=i486 for ilp32 x86_64-*-* and i386-*-* targets. (target_compile): Do not call libgomp_init. Append lang_library_path and lang_link_flags to options. * testsuite/libgomp.c/c.exp: Set DEFAULT_FLAGS to -O2. Set ld_library_path from always_ld_library_path. Set LD_LIBRARY_PATH here. * testsuite/libgomp.c++/c++.exp: Set ld_library_path from always_ld_library_path. Set LD_LIBRARY_PATH here. * testsuite/libgomp.fortran/fortran.exp: Ditto. And no, I didn't volunteer to do the backport ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug rtl-optimization/33927] replace_read in dse.c could handle cases where GET_MODE_CLASS (read_mode) != GET_MODE_CLASS (store_mode) (and the size is the same)
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-03-09 16:51 --- This is one of the issues that I originally tried to fix for 4.3: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01661.html but that was too invasive for stage 3. I resubmitted it after 4.4 opened: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01227.html and pinged it yesterday: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00537.html I'll add the PR number to the change log. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg01227.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2008-03-09 16:51:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33927
[Bug c/35515] New: asm() makes gcc forget about conditionally initialized values
I'll attach a testcase. -- Summary: asm() makes gcc forget about conditionally initialized values Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: samuel dot thibault at ens-lyon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35515
[Bug c/35515] asm() makes gcc forget about conditionally initialized values
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2008-03-09 17:02 --- Erf, sorry, asm constraint problem. -- samuel dot thibault at ens-lyon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35515
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #11 from ubizjak at gmail dot com 2008-03-09 17:09 --- (In reply to comment #10) Can we add a few testcases for Linux/ia32? http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00585.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug c/35516] New: option -masm=intel generates wrong assembly code with globals
Hi
***
unsigned long long foo=0;
int main (void)
{
foo=0;
return 0;
}
***
[EMAIL PROTECTED]:~/dev/C/test4$ gcc -Wall -save-temps -march=opteron
-masm=intel
test1.c -o intel_asm_sample
test1.s: Assembler messages:
test1.s:19: Error: invalid operand for 'mov' ('(' unexpected)
***
[EMAIL PROTECTED]:~/dev/C/test4$ gcc -v
Utilisation des specs internes.
libraries: x86_64-linux-gnu
Configuré avec: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Modèle de thread: posix
version gcc 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
***
Everything is OK without -masm=intel
Everything is OK with variable foo inside main()
Everything is worse when variable foo 0x7fff: we have the same error
twice.
This gcc was released with xubuntu 7.10, I may try a newer gcc version.
Regards
--
Summary: option -masm=intel generates wrong assembly code with
globals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 21valy at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35516
[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words
--- Comment #4 from hutchinsonandy at aim dot com 2008-03-09 18:36 --- The problem is not commutation knowledge to the backend. First - the use notes were a red herring. Reversing them did not help. After much chasing thru call.c and optabs.c, it looks like neither creates nor correct the issue. But I can fix (hide) the issue by commutating the back end expander to get optimal code. (Of course that does not fix ALL binop libcalls!) So I tried a non-commutative operator (% or /) - and that was optimal, with no expander changes. So it would appear that the default don't care order presented to expand_binop() is wrong. Where it does critically matter (non-commutative functions), the order is ideal. The effect on chained arithmetic or higher modes such as DImode is horrendous, and may explain other noted problems with optimizations. FYI here is expander used to temporarily fix (hide) problem - NOTE operand numbering, relative to RTL order. (define_expand mulsi3 [(set (reg:SI 18) (match_operand:SI 1 register_operand r)) (set (reg:SI 22) (match_operand:SI 2 register_operand r)) (parallel [(set (reg:SI 22) (mult:SI (reg:SI 22) (reg:SI 18))) (clobber (reg:HI 26)) (clobber (reg:HI 30))]) (set (match_operand:SI 0 register_operand =r) (reg:SI 22))] AVR_HAVE_MUL ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #23 from t dot artem at mailcity dot com 2008-03-09 19:03 --- Since GCC 4.3.0 is out and this bug is no longer reproducible I suppose it's worth marking this bug as FIXED. Wow, it took exactly two years to fix this bug :-) -- t dot artem at mailcity dot com changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu-gcc |i686-pc-linux-gnu Known to fail|4.2.0 |4.1.2 4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #12 from dominiq at lps dot ens dot fr 2008-03-09 19:32 --- On i686-apple-darwin9 the commited patch of comment #8 fixes the failure for gfortran.dg/array_constructor_12.f90 -O3, but not the failures for gcc.dg/bf-ms-layout*.c which require the patch from comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-09 19:39 --- Subject: Bug 35474 Author: pault Date: Sun Mar 9 19:38:51 2008 New Revision: 133063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133063 Log: 2008-03-09 Paul Thomas [EMAIL PROTECTED] PR fortran/35474 * module.c (mio_symtree_ref): After providing a symbol for a missing equivalence member, resolve and NULL the fixups. 2008-03-09 Paul Thomas [EMAIL PROTECTED] PR fortran/35474 * gfortran.dg/module_commons_2.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/module_commons_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35474
[Bug target/26149] libgomp.c/ordered-2.c fails on x86_64-linux-gnu with -m32
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-03-09 19:40 --- (In reply to comment #5) IIRC, this is a testsuite issue, -march=i486 is not appended automatically to compile flags. This was fixed by following patch series: [...] Uros - It would seem that the first patch written by you and installed on 3/22/2008 was sufficient to fix the problem on x86_64. What was the need for the others, relevant towards this PR? Thanks, --Kaveh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug libgomp/35517] New: OpenMP: Incorrect result when run with two or more threads
The attached program is a straightforward implementation of matrix inversion via the Gauss-Jordan algorithm. The explicitly parallelized version (not attached) produces exactly the same result for each run independent of the number of threads. The version parallelized via OpenMP produces incorrect results for sufficiently large matrices and two or more threads. An example: $ OMP_NUM_THREADS=1 ./matinv_openmp 180 error = 4.75689e-14; epsilon = 2.22045e-16; error / (epsilon * n) = 1.19018 Error within bounds. $ OMP_NUM_THREADS=2 ./matinv_openmp 180 error = nan; epsilon = 2.22045e-16; error / (epsilon * n) = nan Error out of bounds. I compiled this program as follows: $ ~/gcc-4.2.3/bin/gcc -Wall -fopenmp -g matinv_openmp.c -static -o matinv_openmp -lm $ ~/gcc-4.2.3/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/bart/software/gcc-4.2.3/configure --disable-nls --enable-threads=posix --enable-tls --prefix=/home/bart/gcc-4.2.3 Thread model: posix gcc version 4.2.3 -- Summary: OpenMP: Incorrect result when run with two or more threads Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35517
[Bug libgomp/35517] OpenMP: Incorrect result when run with two or more threads
--- Comment #1 from bart dot vanassche at gmail dot com 2008-03-09 19:58 --- Created an attachment (id=15286) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15286action=view) Test program matinv_openmp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35517
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #9 from chris at bubblescope dot net 2008-03-09 20:28 --- Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've previously tended to assume that _GLIBCXX_DEBUG should change only flag code that should fail in non-debug mode, but fails to be detected, whereas _GLIBCXX_DEBUG_PEDANTIC ensures that the code is standards compliant. On another note, could this be added when just -pedantic is added? I think it's a useful flag to add, I'm just trying to avoid having to change a bunch of working, although non standards-complaint code :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug target/26149] libgomp.c/ordered-2.c fails on x86_64-linux-gnu with -m32
--- Comment #7 from ubizjak at gmail dot com 2008-03-09 20:55 --- (In reply to comment #6) Uros - It would seem that the first patch written by you and installed on 3/22/2008 was sufficient to fix the problem on x86_64. What was the need for the others, relevant towards this PR? IIRC, various !x86 targets need their little tweaks, i.e. where they put their dynamic libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #13 from ubizjak at gmail dot com 2008-03-09 21:26 --- (In reply to comment #12) On i686-apple-darwin9 the commited patch of comment #8 fixes the failure for gfortran.dg/array_constructor_12.f90 -O3, but not the failures for gcc.dg/bf-ms-layout*.c which require the patch from comment #5. The patch from Comment #5 disables alignment optimization for darwin. FWIW, these tests fail on x86_64-linux* and i686-linux*, and the failure is probably connected with PR 27948. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #14 from hjl dot tools at gmail dot com 2008-03-09 21:48 --- Does MS bitfield struct require 8byte alignment for long long field for 32bit target? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #9 from danglin at gcc dot gnu dot org 2008-03-09 21:54 --- pr11832.c and pr33009.c are also failing on hppa2.0w-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974
--- Comment #15 from hjl dot tools at gmail dot com 2008-03-09 21:54 --- We may need to update ADJUST_FIELD_ALIGN to support MS-bitfield. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
[Bug middle-end/35518] New: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c -w -O2 -fno-s how-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/20040709-1.x2 (ti meout = 300) PASS: gcc.c-torture/execute/20040709-1.c compilation, -O2 Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc FAIL: gcc.c-torture/execute/20040709-1.c execution, -O2 Breakpoint 2, 0x7afea688 in abort () from /usr/lib/libc.2 (gdb) bt #0 0x7afea688 in abort () from /usr/lib/libc.2 #1 0x6384 in testN () at /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:103 #2 0x78ec in main () at /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:133 Revision 132898 was ok. -- Summary: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709- 1.c execution at -O2 and above Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug target/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-03-09 23:30 --- Subject: Bug 35190 Author: kkojima Date: Sun Mar 9 23:29:49 2008 New Revision: 133064 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133064 Log: Backport from mainline: PR target/35190 * config/sh/sh.md (jump_compact): Disable for crossing jumps. * config/sh/sh.c (find_barrier): Don't go past NOTE_INSN_SWITCH_TEXT_SECTIONS note. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c branches/gcc-4_3-branch/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35190
[Bug target/35225] [4.2 regression] gcc segfaults when building GTK+ code with -O2 -fPIC for SH4
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-03-09 23:32 --- Subject: Bug 35225 Author: kkojima Date: Sun Mar 9 23:31:26 2008 New Revision: 133065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133065 Log: Backport from mainline: PR target/35225 * config/sh/sh.c (find_barrier): Don't go past 'from' argument. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35225
[Bug target/35225] [4.2 regression] gcc segfaults when building GTK+ code with -O2 -fPIC for SH4
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-03-09 23:40 --- Subject: Bug 35225 Author: kkojima Date: Sun Mar 9 23:39:51 2008 New Revision: 133066 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133066 Log: Backport from mainline: PR target/35225 * config/sh/sh.c (find_barrier): Don't go past 'from' argument. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35225
[Bug target/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-03-09 23:44 --- fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35190
[Bug target/35225] [4.2 regression] gcc segfaults when building GTK+ code with -O2 -fPIC for SH4
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-03-09 23:45 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35225
[Bug testsuite/35406] gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c don't work
--- Comment #3 from danglin at gcc dot gnu dot org 2008-03-09 23:47 --- Also fails on hppa2.0w-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35406
[Bug middle-end/35519] New: COMBINE repeating same matches and can SEG fault
This problem potentiall affects all all targets
The data flow information that combine uses can cause Segmentation fault. I
have found this with AVR experimental build but it would seem that it can
affect any target.
The problem is that the LOG_LINKS that combine creates from DF can include
multiple references between instruction pairs.
DF will produce multiple reference between instructions if they share a
register that decomposes into several smaller registers.
The multiple cross references are then used by Combine to select instruction
pairs and triples to match. This results in repeat trials of the same
instructions!
By was on an example, tThe RTL that triggered my problem was:
(insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ])
(mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil))
(insn 46 45 47 4 920625-1.c:55 (set (reg:SI 18 r18)
(mem:SI (plus:HI (reg:HI 68 [ ivtmp.18 ])
(const_int 4 [0x4])) [2 S4 A8])) 19 {*movsi} (nil))
(insn 47 46 48 4 920625-1.c:55 (parallel [
(set (reg:SI 22 r22)
(mult:SI (reg:SI 22 r22)
(reg:SI 18 r18)))
(clobber (reg:HI 26 r26))
(clobber (reg:HI 30 r30))
]) 43 {*mulsi3_call} (expr_list:REG_DEAD (reg:SI 18 r18)
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(nil)
This is call to library function, and the parameter for instruction 47 are hard
registers like SI:R22 - which is decomposed in DF as R22,23,24 and 25.
DF marks all 4 sub parts in def/use chains (which seems entirely correct)
When DF information is transferred into LOG_LINKS we still have 4 references
back to the definition in instructions 45 and 47. From gdb this was:
(gdb) print uid_log_links[47]
$8 = (rtx) 0x7ff140d0
(gdb) pr
(insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE
45
(insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 46 (insn_list:REG_DEP_TRUE 4
6 (insn_list:REG_DEP_TRUE 46 (insn_list:REG_DEP_TRUE 46 (nil)
These multiple references causes COMBINE to try the same combination of
instruction 45 and 47 multiple times ( thinking they are different
instructions). In this case the match is tried 4 times - 3 more than needed.
Thi part appears most benign - except for processing time/memory used.
BUT when combine tries three instructions, it can crash. In this example,
combine ends up trying to combine 2 duplicate instruction 45 with 47:
I1=
(insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ])
(mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil))
I2=
(insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ])
(mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil))
I3=
(insn 47 46 48 4 920625-1.c:55 (parallel [
(set (reg:SI 22 r22)
(mult:SI (reg:SI 22 r22)
(reg:SI 18 r18)))
(clobber (reg:HI 26 r26))
(clobber (reg:HI 30 r30))
]) 43 {*mulsi3_call} (expr_list:REG_DEAD (reg:SI 18 r18)
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(nil)
Combine merges I1 into i3 and deletes I1. Combine notes that the life of R22
terminates in I2 and attempt to put a REG_DEAD note on I2 - except of course
the deletion of I1 also deletes the identical i2. Segmentation fault occurs.
--
Summary: COMBINE repeating same matches and can SEG fault
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at aim dot com
GCC host triplet: i686-oc-cyqwin
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519
[Bug middle-end/35519] COMBINE repeating same matches and can SEG fault
--- Comment #1 from hutchinsonandy at aim dot com 2008-03-09 23:52 --- Created an attachment (id=15287) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15287action=view) Patch for consideratiom towards a solution Patch that removes duplicates when LOG_LINKS is created. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519
[Bug testsuite/35406] gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c don't work
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-03-10 00:08 --- If it is just the test case I will attempt to fix it. If anyone else is already doing so, please let me know so I don't waste my time. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-03-06 18:34:21 |2008-03-10 00:08:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35406
[Bug c/35489] Inaccurate GCC documentation
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-10 00:37 --- @Adam, If you think that something is wrong in the documentation, please point out exactly which text should be removed and what should be added. Also, feel free to submit a documentation patch: http://gcc.gnu.org/contribute.html#docchanges A patch would certainly help to clarify why you think the current doc is wrong and what you think should be the correct wording. As for GCC issues with fp precision, it is an ongoing debate. It is not crystal clear which optimizations (if any) GCC should avoid for the sake of precision. The main sources of info right now are: http://gcc.gnu.org/wiki/FP_BOF http://gcc.gnu.org/wiki/Math_Optimization_Flags http://gcc.gnu.org/wiki/GeertBosch If after reading those, you think that you can contribute something new or you still think that some issue should be revisited, then submit an email to the [EMAIL PROTECTED] list. Please, focus on a particular issue, with examples and reasoning. As always, patches and testcases would further help your cause. Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35489
[Bug c/35489] Inaccurate GCC documentation
--- Comment #4 from manu at gcc dot gnu dot org 2008-03-10 00:52 --- (In reply to comment #2) Actually, I like that response. I might try to use it myself next time one of our customers reports a problem. I guess that your contracted GCC support developers may give you a reply that you like even more, so better go ask them. (That wouldn't be a nice reply, would it? So please understand that your jest isn't nice to us either. We are happy to receive and fix bug reports, but politeness certainly helps when asking for something.) -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-03-10 00:52:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35489
[Bug java/35257] jar: internal error: java.lang.NullPointerException bootstrapping libjava
--- Comment #3 from gerald at pfeifer dot com 2008-03-10 01:35 --- (In reply to comment #2) Based on the command line it looks like your system gjar is crashing. Is that the case? Good point. Yes, that seems to be the case, and I asked Richi about it. -- gerald at pfeifer dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35257
[Bug rtl-optimization/33927] replace_read in dse.c could handle cases where GET_MODE_CLASS (read_mode) != GET_MODE_CLASS (store_mode) (and the size is the same)
--- Comment #2 from Kenneth dot Zadeck at NaturalBridge dot com 2008-03-10 01:48 --- I tested the latest patch on ppc-32 and ppc-64 and there were no regressions. i did have trouble applying the patch. The second frag of the update for the test case did not apply. -- Kenneth dot Zadeck at NaturalBridge dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33927
[Bug bootstrap/35521] New: gcc-3.4.4 build on solaris -10 failing
i am trying to build gcc-3.4.4 on solaris -10..i am getting an error in the build stage csbu061 [toolsrd] 703: make build creating cache ./config.cache checking host system type... sparc-sun-solaris2.10 checking target system type... sparc-sun-solaris2.10 checking build system type... sparc-sun-solaris2.10 checking for a BSD compatible install... /users/toolsrd/ws/si_ctoolrd/gcc/production/sources/gcc-3.4.4/install-sh -c *** This configuration is not supported in the following subdirectories: target-libf2c target-libobjc (Any other directories should still work fine.) checking for sparc-sun-solaris2.10-ar... no checking for ar... ar checking for sparc-sun-solaris2.10-as... no checking for as... as checking for sparc-sun-solaris2.10-dlltool... no checking for dlltool... dlltool checking for sparc-sun-solaris2.10-ld... /tools/openbin/binutils/2.16.1/sparc-sun-solaris8/bin/ld checking for sparc-sun-solaris2.10-nm... no checking for nm... nm checking for sparc-sun-solaris2.10-ranlib... no checking for ranlib... ranlib checking for sparc-sun-solaris2.10-windres... no checking for windres... windres checking for sparc-sun-solaris2.10-objcopy... no checking for objcopy... objcopy checking for sparc-sun-solaris2.10-objdump... no checking for objdump... objdump checking for sparc-sun-solaris2.10-ar... no checking for ar... ar checking for sparc-sun-solaris2.10-as... no checking for as... as checking for sparc-sun-solaris2.10-dlltool... no checking for dlltool... dlltool checking for sparc-sun-solaris2.10-ld... no checking for ld... ld checking for sparc-sun-solaris2.10-nm... no checking for nm... nm checking for sparc-sun-solaris2.10-ranlib... no checking for ranlib... ranlib checking for sparc-sun-solaris2.10-windres... no checking for windres... windres checking whether to enable maintainer-specific portions of Makefiles... no updating cache ./config.cache creating ./config.status creating Makefile sh: : not found *** Error code 1 dmake: Fatal error: Command failed for target `build-gcc' csbu061 [toolsrd] 704: ** i am using binutils-2.16.1 for assembler and linker and gcc-3.4.4 compiler build on solaris-8 for initial bootstrapping -- Summary: gcc-3.4.4 build on solaris -10 failing Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: halder dot malay at gmail dot com GCC build triplet: sparc sun-solaris 10 GCC host triplet: sparc sun-solaris 10 GCC target triplet: sparc sun-solaris 10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35521
