[Bug middle-end/17402] static functions are removed before builtins are expanded
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-23 06:06 --- I don't care about this anymore. Perhaps this should be an invalid bug, oh well. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17402
[Bug target/23525] New: inefficient parameter passing on x86
Compiling this code:
extern int waiting_for_initial_map;
extern int close (int __fd);
void
first_map_occurred(void)
{
close(cp_pipe[0]);
close(pc_pipe[1]);
waiting_for_initial_map = 0;
}
using -O2 -march=i686 4.[01] generate sequences like:
movlcp_pipe, %eax
movl%eax, (%esp)
for calling the close function
the Intel compiler generates:
pushl cp_pipe
--
Summary: inefficient parameter passing on x86
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23525
[Bug middle-end/22043] [4.1 Regression] Fields not initialized for automatic structs with flexible array members
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 07:28 --- Subject: Bug 22043 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 07:28:26 Modified files: gcc: ChangeLog expr.c gimplify.c tree-sra.c tree.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050613-1.c Log message: PR tree-optimization/22043 * tree.h (count_type_elements): Add ALLOW_FLEXARR argument. * expr.c (count_type_elements): Add ALLOW_FLEXARR argument. If ALLOW_FLEXARR, handle types ending with flexible array member. Pass false as second argument to recursive count_type_elements calls. (categorize_ctor_elements_1, mostly_zeros_p): Pass false as second argument to count_type_elements call. * tree-sra.c (decide_block_copy): Likewise. * gimplify.c (gimplify_init_constructor): If num_type_elements 0 for a constant-sized object, set cleared as well. Pass true as second argument to count_type_elements call. * gcc.c-torture/execute/20050613-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9803r2=2.9804 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.808r2=1.809 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.147r2=2.148 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gccr1=2.70r2=2.71 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.753r2=1.754 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5951r2=1.5952 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050613-1.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22043
[Bug tree-optimization/23511] [4.1 Regression] Segfault in fold_binary
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 08:15 --- Subject: Bug 23511 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 08:15:19 Modified files: gcc: ChangeLog tree-ssa-loop-niter.c Log message: PR tree-optimization/23511 * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined): Don't handle cases where TYPE_MIN_VALUE or TYPE_MAX_VALUE are NULL_TREE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9804r2=2.9805 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gccr1=2.39r2=2.40 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23511
[Bug java/23431] [4.0/4.1 regression] gcj allows overriding with more restrictive access
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23
09:50 ---
Changed synopsis and component. Added keyword.
Interestingly, the following is (wrongly) accepted:
- 8 -
interface MyRunnable
{
public void run( );
}
class Snafu implements MyRunnable
{
private void run( ) { }
}
- 8 -
but *not* the following:
- 8 -
abstract class MyRunnable
{
public abstract void run( );
}
class Snafu extends MyRunnable
{
private void run( ) { }
}
- 8 -
--
What|Removed |Added
Component|libgcj |java
Keywords||accepts-invalid
Last reconfirmed|2005-08-22 19:12:07 |2005-08-23 09:50:28
date||
Summary|[4.0/4.1 regression] gcj|[4.0/4.1 regression] gcj
|allows overriding with less |allows overriding with more
|restrictive access |restrictive access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug libstdc++/23494] std::basic_string capacity weirdness
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:56 --- When push_back notices that s1 is shared and clones it (via reserve), creates a new string (not shared) of capacity = original size (according to an exponential grow policy) but unrelated to the original capacity. I don't think it would be wise to always take into account the original capacity, which can be size for *zillions* of different reasons, depending on the history of the string, and not explicitly requested by the user via a previous reserve. Also notice that a *series* of push_back is typically very fast, because of the exponential reallocation policy and very often there is no real need for a reserve to obtain good performance. Also notice that some artifacts are generally considered unavoidable in a reference counted implementation of string, as our default one (in mainline, we provide also an alternate implementation in ext/vstring.h) -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
[Bug libstdc++/23465] Assignment fails on TR1 unordered containers
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:57 --- Thanks Chris. I will work on this issue. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 09:57:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23465
[Bug target/20102] Incorrect floating point code generated when assigning to packed structure
--- Additional Comments From oakad at yahoo dot com 2005-08-23 10:27 --- I was dealing with packed structs in this case. Are you sure that -mstrict-align will not break packing? And I'm talking of both inter- and intra-struct packing, as in packed array of packed structs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20102
[Bug libstdc++/23494] std::basic_string capacity weirdness
--- Additional Comments From pcarlini at suse dot de 2005-08-23 10:22 --- Of course, first copy-constructing s2, then calling s1.reserve also makes sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 10:40 --- Subject: Bug 23358 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 10:40:14 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_construct.h Log message: 2005-08-23 Thomas Kho [EMAIL PROTECTED] PR libstdc++/23358 * include/bits/stl_construct.h (_Destroy(_ForwardIterator, _ForwardIterator, allocator_Tp)): Removed unused template parameter. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3074r2=1.3075 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_construct.h.diff?cvsroot=gccr1=1.21r2=1.22 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug tree-optimization/23511] [4.1 Regression] Segfault in fold_binary
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:10 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23511
[Bug middle-end/22043] [4.1 Regression] Fields not initialized for automatic structs with flexible array members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:11 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22043
[Bug ada/23514] fixed point error cause Ada exception block does NOT work
--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-23 11:25 --- You need to use -gnato if you want an exception here. This test case in any case is handled as expected in GCC 4.1 as far as I can see, unless the mingw build is too old or using non standard sources, but you didn't specify source dates. Arno -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23514
[Bug rtl-optimization/23523] code size regression on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:26 --- This is an ra issue. There is only one load from pc_pipe[1] which x86 does not like. There is an actually a different on the tree level but the ra should have handled that but it does not. -- What|Removed |Added BugsThisDependsOn||18427 Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2005-08-23 11:26:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23524] bigger version of mov + cmp produced
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:27 --- You really should know that we only care about code size at -Os. We care about performance regressions though at -O2. -- What|Removed |Added Summary|bigger version of mov + cmp |bigger version of mov + cmp |produced|produced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:34 --- (In reply to comment #20) gcc shouldn't always error out in this situation. For suspend to disk, we clobber all registers when restoring the original cpu context after copying back the original kernel context. We could lie to gcc and say we don't clobber the register, but I'd prefer to be honest : You know you can use a function to do that and a .s file for that right? You don't need to use an inline- asm, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From nigel at suspend2 dot net 2005-08-23 11:31 --- gcc shouldn't always error out in this situation. For suspend to disk, we clobber all registers when restoring the original cpu context after copying back the original kernel context. We could lie to gcc and say we don't clobber the register, but I'd prefer to be honest : Nigel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug target/21571] ICE in rs6000.c with -msdata=default.
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Additional Comments From ncunningham at cyclades dot com 2005-08-23 11:41 --- Subject: Re: GCC should error out when clobbering the stack pointer and frame pointer The function needs to be inlined - the return value especially is pivotal in the transition from the booted kernel context to the suspended one. That said, I'm no x86 assembly guru, so there might be a way around it. Regards, Nigel On Tue, 2005-08-23 at 21:34, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:34 --- (In reply to comment #20) gcc shouldn't always error out in this situation. For suspend to disk, we clobber all registers when restoring the original cpu context after copying back the original kernel context. We could lie to gcc and say we don't clobber the register, but I'd prefer to be honest : You know you can use a function to do that and a .s file for that right? You don't need to use an inline- asm, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug c++/23526] Internal compiler error with -03 optimization in c++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:41 --- This is a dup of bug 23454. Also please don't copy and paste the preprocessed source into gccbug. Instead wait to the confirmation email and attach it to the bug in the web interface or attach it (and not inlined) to an email to [EMAIL PROTECTED] with the subject of the bug : . *** This bug has been marked as a duplicate of 23454 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23526
[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:42 --- *** Bug 23526 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||georg dot oppenberg at deu ||dot mci dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454
[Bug c++/23426] [4.0/4.1 Regression] Too large array problem gives two error message
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:44 --- earth:~gcc t.cc t.cc: In function int main(): t.cc:19: error: size of array a is too large t.cc:20: error: a was not declared in this scope earth:~~/ia32_linux_gcc3_4/bin/gcc t.cc t.cc: In function `int main()': t.cc:19: error: size of variable 'a' is too large earth:~gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/peshtigo/pinskia/src/gnu/gcc/src/configure --target=i686-pc-linux-gnu -- host=i686-pc-linux-gnu --enable-__cxa_atexit --enable-languages=c++,objc,java,f95 --prefix=/ home/gates/pinskia/linux --enable-threads=posix --enable-shared Thread model: posix gcc version 4.1.0 20050823 (experimental) So the error message is also a regression but that makes this minor as the first error message is correct. -- What|Removed |Added Severity|normal |minor Keywords|ice-on-invalid-code |diagnostic Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Summary|[4.0/4.1 Regression] partial|[4.0/4.1 Regression] Too |fix too large array problem |large array problem gives ||two error message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23426
[Bug libgcj/23507] gij testsuite failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 11:46 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23507
[Bug libgcj/23508] FAIL: PR218
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 11:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23508
[Bug libstdc++/23528] New: Wrong default allocator in ext/hash_map
The attached testcase compiles and runs correctly with gcc 3.3.4, but gives the following compilation errors with gcc 3.4.4: hashtest.cxx: In function `int main()': hashtest.cxx:11: error: cannot convert `int*' to `std::pairconst int, int*' in initialization hashtest.cxx:12: error: no matching function for call to `std::allocatorint::construct(std::pairconst int, int*, std::pairconst int, int)' /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../../include/c++/3.4.4/ext/new_allocator.h:96: note: candidates are: void __gnu_cxx::new_allocator_Tp::construct(_Tp*, const _Tp) [with _Tp = int] hashtest.cxx:17: error: no matching function for call to `std::allocatorint::destroy(std::pairconst int, int*)' /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../../include/c++/3.4.4/ext/new_allocator.h:99: note: candidates are: void __gnu_cxx::new_allocator_Tp::destroy(_Tp*) [with _Tp = int] hashtest.cxx:18: error: no matching function for call to `std::allocatorint::deallocate(std::pairconst int, int*, int)' /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../../include/c++/3.4.4/ext/new_allocator.h:86: note: candidates are: void __gnu_cxx::new_allocator_Tp::deallocate(_Tp*, size_t) [with _Tp = int] The reason for the errors are wrong default allocators in ext/hash_map. A patch that fixes the problem is attached. -- Summary: Wrong default allocator in ext/hash_map Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mattias dot ellert at tsl dot uu dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] Wrong default allocator in ext/hash_map
--- Additional Comments From mattias dot ellert at tsl dot uu dot se 2005-08-23 12:01 --- Created an attachment (id=9563) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9563action=view) The testcase that exemplifies the error It fails with gcc 3.4.4 but works correctly with gcc 3.3.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] Wrong default allocator in ext/hash_map
--- Additional Comments From mattias dot ellert at tsl dot uu dot se 2005-08-23 12:02 --- Created an attachment (id=9564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9564action=view) Patch against the gcc 3.4.4 STL headers With this patch applied to gcc 3.4.4 it compiles correctly with this compiler too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 12:27 --- Subject: Bug 23467 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 12:26:38 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: pr23467.c Log message: gcc: PR middle-end/23467 * stor-layout.c (finalize_type_size): Dont override existing alignment with a smaller alignment from the mode. testsuite: PR middle-end/23467 * gcc.c-torture/execute/pr23467.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5952r2=1.5953 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr23467.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 12:28 --- Subject: Bug 23467 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 12:27:55 Modified files: gcc: ChangeLog stor-layout.c Log message: gcc: PR middle-end/23467 * stor-layout.c (finalize_type_size): Dont override existing alignment with a smaller alignment from the mode. testsuite: PR middle-end/23467 * gcc.c-torture/execute/pr23467.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9806r2=2.9807 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gccr1=1.238r2=1.239 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
[Bug c++/23044] [4.0/4.1 Regression] ICE on valid code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 12:36 --- Subject: Bug 23044 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 12:35:42 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: instantiate8.C Log message: cp: PR c++/23044 * pt.c (tsubst_qualified_id): A SCOPE_REF can still remain. testsuite: PR c++/23044 * g++.dg/template/instantiate8.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4856r2=1.4857 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.1024r2=1.1025 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5953r2=1.5954 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/instantiate8.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044
[Bug c++/18835] memory consumption is high for C++ testcase
-- Bug 18835 depends on bug 23044, which changed state. Bug 23044 Summary: [4.0/4.1 Regression] ICE on valid code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18835
[Bug c++/23044] [4.0/4.1 Regression] ICE on valid code
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-23 12:38 --- fixed mainline and 4.0 2005-08-23 Nathan Sidwell [EMAIL PROTECTED] PR c++/23044 * pt.c (tsubst_qualified_id): A SCOPE_REF can still remain. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044
[Bug c++/23044] [4.0/4.1 Regression] ICE on valid code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 12:39 --- Subject: Bug 23044 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-23 12:38:53 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: instantiate8.C Log message: cp: PR c++/23044 * pt.c (tsubst_qualified_id): A SCOPE_REF can still remain. testsuite: PR c++/23044 * g++.dg/template/instantiate8.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/instantiate8.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.80r2=1.4648.2.81 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.978.2.17r2=1.978.2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.345r2=1.5084.2.346 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 12:42 --- This works in both on the mainlline and in 4.0.0. Also the fix is not really a correct fix as this area was not what changed between 3.4.0 and 4.0.0. -- What|Removed |Added Known to fail||3.4.0 Known to work||3.3.3 4.0.0 4.1.0 Summary|Wrong default allocator in |[3.4 Regression] Wrong |ext/hash_map|default allocator in ||ext/hash_map Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug middle-end/23467] alignment of member doesn't always carry over to alignment of struct.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 12:45 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
[Bug driver/23351] *cpp specs file options are sometimes ignored in Sun builds
--- Additional Comments From matti dot rintala at iki dot fi 2005-08-23 12:47 --- (In reply to comment #3) You can set env variables per user. Are you saying that specs files and specs options are not supported in current gcc and that they should not be used for any purpose? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23351
[Bug driver/23351] *cpp specs file options are sometimes ignored in Sun builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 12:49 --- (In reply to comment #4) (In reply to comment #3) You can set env variables per user. Are you saying that specs files and specs options are not supported in current gcc and that they should not be used for any purpose? No what I am saying is that they are not designed for what you are doing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23351
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:15 --- I agree that something much more subtle is going on, maybe even a C++ front-end bug in 3_4-branch. Notice that hash_map::allocator_type is typedef-ed as _Ht::allocator_type, which, in turn (see the hashtable class in hashtable.h) is, correctly, an allocator of pairconst _Key, _Tp. Likewise for hash_map::value_type. More analysis is required... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug c/23506] [4.0/4.1 Regression] Bad array access in DEF_GCC_BUILTIN
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 13:15 --- Confirmed, this is a regression from 3.4.0 where we did not have this access. It looks like it was caused by: 2005-02-09 Richard Henderson [EMAIL PROTECTED] * builtins.c (DEF_BUILTIN): Add COND argument. * tree.h (DEF_BUILTIN): Likewise. * builtins.def (DEF_GCC_BUILTIN, DEF_LIB_BUILTIN, DEF_EXT_LIB_BUILTIN, DEF_C94_BUILTIN, DEF_C99_BUILTIN, DEF_C99_C90RES_BUILTIN): Update to match. (DEF_BUILTIN_STUB): New. (BUILT_IN_STACK_SAVE, BUILT_IN_STACK_RESTORE, BUILT_IN_INIT_TRAMPOLINE, BUILT_IN_ADJUST_TRAMPOLINE, BUILT_IN_NONLOCAL_GOTO, BUILT_IN_PROFILE_FUNC_ENTER, BUILT_IN_PROFILE_FUNC_EXIT): Use it. * c-common.c (DEF_BUILTIN): Add COND argument. * tree.c (local_define_builtin): New. (build_common_builtin_nodes): New. -- What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 13:16:00 date|| Summary|Bad array access in |[4.0/4.1 Regression] Bad |DEF_GCC_BUILTIN |array access in ||DEF_GCC_BUILTIN Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23506
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 13:18 --- I forgot to mention that the preprocessed source from 4.1.0 compiles just fine with the 3.4.0 compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:26 --- (In reply to comment #5) I find this very hard to believe: the ext/ headers are basically frozen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:34 --- (In reply to comment #6) Ok, Andrew is right, just double checked. A big mistery... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:42 --- (In reply to comment #7) A big mistery... Actually, in 3_4-branch memory allocation in class hashtable was rather different, forgot about that. The bug is there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 13:42 --- Oh and the preprocessed created with 3.4.0 gives the same error on the mainline too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:55 --- It looks like the problem has been fixed in revision 1.6 of hashtable.h. Mattias, can you experiment a bit with just changing in class hashtable: typedef _Alloc allocator_type; to typedef typename _Alloc::template rebindvalue_type::other allocator_type; (likely, you have available code using hash_map much more complex than I do) -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug java/23283] Sun's JIT faster than gcc for Random.nextDouble
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23 14:15 --- I see this too. Compiling with -fno-bounds-check helps, but not enough. One possibility is simply that our implementation of nextDouble is inefficient. I doubt this function was coded for maximum performance. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 14:15:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
[Bug fortran/12840] Unable to find scalarization loop specifier
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-08-23 14:19 --- Working on a patch. -- What|Removed |Added AssignedTo|pbrook at gcc dot gnu dot |rsandifo at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12840
[Bug libgcj/23216] IncompatibleClassChangeError when Using Java-Gnome
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23 14:19 --- I tried this with the gcc 4.0 and java-gnome that ship on Fedora Core 4. It worked for me. Can you give some more information? Perhaps the stack trace that you see? Did you compile this or run it interpreted? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23216
[Bug java/23283] Sun's JIT faster than gcc for Random.nextDouble
--- Additional Comments From mark at klomp dot org 2005-08-23 14:31 --- Subject: Re: Sun's JIT faster than gcc for Random.nextDouble It looks like the problem is that we don't remove the synchronization for nextDouble() even though the test case is single-threaded. qprof: /tmp/x: 299 samples, 299 counts X::main(JArrayjava::lang::String**):X.java:8 5 ( 2%) libc.so.6(memchr)1 ( 0%) libgcj.so.6 2 ( 1%) libgcj.so.6(_Jv_MonitorEnter)110( 37%) libgcj.so.6(_Jv_MonitorExit) 108( 36%) libgcj.so.6(_ZN4java4util6Random4nextEi) 27 ( 9%) libgcj.so.6(_ZN4java4util6Random10nextDoubleEv) 46 ( 15%) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
[Bug libgcj/20908] [m68k-linux] libjava testsuite fails about 600 tests
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23 14:36 --- This still seems quite high: # of unexpected failures91 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20908
[Bug ada/23514] fixed point error cause Ada exception block does NOT work
--- Additional Comments From kuan_long at hotmail dot com 2005-08-23 14:43 --- -gnato still fail in Mingw 4.1 ,the OS is windows XP gcc -v Reading specs from C:/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as -- host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable -languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared -- e nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable- ja va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash- synchroniz ation --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23514
[Bug driver/23532] New: [gfortran g77] Regression compiling Fortran code with preprocessor instructions
Fortran code containing preprocessor instructions needed for handling
system-specific behaviour is traditionally written to files with
the extension .F (rather than .f). The GCC driver would preprocess this
file in a first step, writing the intermediate code to a temporary .f file.
The regression (observed with both GCC 4.0.1 (gfortran) and GCC 3.3.6 (g77))
is that the preprocessing stage fails (3.3.6) when any Fortran-specific options
are used (e.g. '-Wsurprising' as an option known to both gfortran and g77)
or issues a warning about an unrecognized option (4.0.1).
This worked in older versions (tested with 3.4.3, 3.3.3, 3.2, 3.0.4).
If the code in the .F file does not contain preprocessor instructions, one
could explicitly set the language ('-x f77') to force acceptance of the
Fortran specific options - but the preprocessor stage is skipped then
in all GCC versions, just as if using a .f file name extension.
To fix this regression, the preprocessing stage should accept (and ignore) the
Fortran-specific options, as it used to be in earlier versions.
Not sure if this should be assigned to the preprocessor or the driver component.
While 4.0.1 just issues an irritating warning and continues, no
Fortran-specific options can be used anymore for .F files to be preprocessed
in 3.3.6 (and perhaps 3.4.4, untested).
Demonstration script hello.sh (use as 'FC=g77 ./hello.sh' with GCC 3.x.x):
#!/bin/sh
if [ -z $FC ]; then
FC=gfortran
fi
set -x
cat hello.f EndOfF
Program MAIN
#ifdef TEST1
Write(*,*) 'Hello, world no. 1'
#else
Write(*,*) 'Hello, world no. 2'
#endif
End
EndOfF
ln -sf hello.f hello.F
echo Without Fortran-specific option compilation works fine:
${FC} -g -Wall -DTEST1 hello.F -o hello1
./hello1
${FC} -g -Wall hello.F -o hello2
./hello2
echo Both gfortran and g77 version 3.3.6 (perhaps also 3.4.4?) fail/complain
echo with Fortran-specific options while older g77 version are OK:
${FC} -g -Wall -Wsurprising hello.F -o hello
echo When setting the language explicitly, the preprocessor is skipped:
${FC} -g -Wall -Wsurprising -x f77 hello.F -o hello
--
Summary: [gfortran g77] Regression compiling Fortran code with
preprocessor instructions
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Konrad dot Bernloehr at mpi-hd dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i586-mandriva-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23532
[Bug java/23283] Sun's JIT faster than gcc for Random.nextDouble
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:48 ---
Yes, I think that most invocations of next should be inlined, and wrapped in a
single synchronized block.
Apart from that, I am pretty sure that here
seed = (seed * 0x5DEECE66DL + 0xBL) ((1L 48) - 1);
return (int) (seed (48 - bits));
it makes no difference if you do the AND or not.
So nextDouble could be implemented as:
long first;
long second;
synchronized (this) {
seed = (seed * 0x5DEECE66DL + 0xBL);
first = (seed 0xFFC0L) 5;
seed = (seed * 0x5DEECE66DL + 0xBL);
second = (seed 21) 0x7FF;
}
return (first | second) / (double) (1L 53);
Similarly, for nextFloat
float f;
int bits;
synchronized (this) {
seed = (seed * 0x5DEECE66DL + 0xBL);
bits = (int) (seed 24);
}
return bits / 16777216.0f;
nextInt
int bits;
synchronized (this) {
seed = (seed * 0x5DEECE66DL + 0xBL);
bits = (int) (seed 16);
}
nextLong
long first, second;
synchronized (this) {
seed = (seed * 0x5DEECE66DL + 0xBL);
first = (seed 16) 0xL;
seed = (seed * 0x5DEECE66DL + 0xBL);
second = (seed 16) 0xL;
}
return first | second;
nextInt (n)
int bits;
synchronized (seed)
{
seed = (seed * 0x5DEECE66DL + 0xBL);
bits = (int) (seed 17);
}
if ((n -n) == n) // i.e., n is a power of 2
return (int)((n * (long) bits) 31);
int bits, val;
val = bits % n;
if (bits - val + n - 1 0)
synchronized (seed)
{
do
{
seed = (seed * 0x5DEECE66DL + 0xBL);
bits = (int) (seed 17);
}
while (bits - val + n - 1 0);
}
return val;
nextBoolean
boolean bit;
synchronized (this) {
seed = (seed * 0x5DEECE66DL + 0xBL);
bit = (seed 0x8000) != 0;
}
return bit;
And I left out nextBytes, I know.
Also these are untested, which is why I'm not preparing a full patch.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
[Bug java/23283] Sun's JIT faster than gcc for Random.nextDouble
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23 14:51 --- It looks like the problem is that we don't remove the synchronization for nextDouble() even though the test case is single-threaded. If we can remove even only half of the synchronization overhead, by synchronizing just once per nextDouble() call, it's a win. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
[Bug driver/23532] [gfortran g77] Regression compiling Fortran code with preprocessor instructions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 14:54 --- The gfortran bug is PR 18452. The g77 bug was PR 13008 and was fixed in 3.4.0. I am going to close this as a dup of the gfortran bug. *** This bug has been marked as a duplicate of 18452 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23532
[Bug fortran/18452] Fortran options induces warning for fortran that needs preprocessing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 14:54 --- *** Bug 23532 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Konrad dot Bernloehr at mpi- ||hd dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug other/22594] HOST_LONG_LONG_FORMAT not used in HOST_WIDE_INT_PRINT macro
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 15:06 --- Fixed by: +2005-08-23 Mark Mitchell [EMAIL PROTECTED] + + * hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT. + -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594
[Bug ada/23514] fixed point error cause Ada exception block does NOT work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 15:12 --- This is a target bug. http://groups-beta.google.com/group/comp.lang.ada/browse_thread/thread/ee1a8b8db84c88f/ 2195130b88e4dc9d? lnk=stq=Ada+exception+block+does+NOT+work%3Frnum=1#2195130b88e4dc9d Most likely use of setjump/longjump does not work with signals and/or windows signals are handled funny. -- What|Removed |Added GCC target triplet||mingw32 Target Milestone|4.1.1 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23514
[Bug c/23535] New: Compiler assertion failed when building cross compiler
The compiler generates the following error (includes command building the file) when building a cross compiler out of GCC HEAD. This also happens on the 20050813 snapshot but does NOT happen on the May 15, 2005 snapshot. - Pasted console log below - /home/tlaurenzo/gcc_build/mingwhead/build/gcc-4.1-20050813/./gcc/xgcc -B/home/tlaurenzo/gcc_build/mingwhead/build/gcc-4.1-20050813/./gcc/ -B/home/tlaurenzo/gcc_build/mingwhead/gcc_cross/i686-pc-mingw32/bin/ -B/home/tlaurenzo/gcc_build/mingwhead/gcc_cross/i686-pc-mingw32/lib/ -isystem /home/tlaurenzo/gcc_build/mingwhead/gcc_cross/i686-pc-mingw32/include -isystem /home/tlaurenzo/gcc_build/mingwhead/gcc_cross/i686-pc-mingw32/sys-include -c -DHAVE_CONFIG_H -O2 -O2 -pipe -g0 -I. -I/home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -fpic /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c -o pic/fopen_unlocked.o; \ else true; fi /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c:1: warning: -fpic ignored for target (all code is position independent) /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c: In function 'unlock_std_streams': /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c:98: error: invariant not recomputed when ADDR_EXPR changed _iobD.1290[1]; /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c:98: error: invariant not recomputed when ADDR_EXPR changed _iobD.1290[2]; /home/tlaurenzo/gcc_build/mingwhead/src/gcc-4.1-20050813/libiberty/fopen_unlocked.c:98: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [fopen_unlocked.o] Error 1 -- Summary: Compiler assertion failed when building cross compiler Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tj at laurenzo dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23535
[Bug c/23535] Compiler assertion failed when building cross compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 15:44 --- *** This bug has been marked as a duplicate of 21766 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23535
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 15:44 --- *** Bug 23535 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tj at laurenzo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug libgcj/23182] instanceof sometimes fails if compiled with -findirect-dispatch
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23 16:02 --- Also fails with cvs head. Offhand I suspect a compiler bug. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 16:02:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182
[Bug libgcj/23216] IncompatibleClassChangeError when Using Java-Gnome
--- Additional Comments From ajocksch at redhat dot com 2005-08-23 16:05 --- Sorry, I should have clarified earlier that I'm developing with Java-Gnome head. I am running it interpreted through Eclipse. Here's the stack trace it generates: Exception in thread main java.lang.IncompatibleClassChangeError at org.gnu.glib.GObject.getGObjectFromHandle(org.gnu.javagnome.Handle) (Unknown Source) at org.gnu.gtk.TextBuffer.getTextBuffer(org.gnu.javagnome.Handle) (Unknown Source) at org.gnu.gtk.TextView.getBuffer() (Unknown Source) at TestCase.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23216
[Bug c++/18835] memory consumption is high for C++ testcase
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 16:27 --- tree.c:5027 (build_method_type_directly)7305888: 3.6% 0: 0.0% 596640: 0.9% 0: 0.0% 82318 cp/name-lookup.c:1241 (begin_scope) 8848872: 4.3% 0: 0.0% 2376: 0.0% 1639120: 7.5% 81956 cp/lex.c:748 (copy_decl) 60144: 0.0% 0: 0.0%9639560:14.1% 157880: 0.7% 83327 varray.c:141 (varray_init) 9824868: 4.8% 128820: 0.3%400: 0.0%1946552: 8.9% 35661 cp/pt.c:5973 (tsubst_template_args)10984652: 5.4% 0: 0.0%3331804: 4.9% 576712: 2.6% 441940 cp/pt.c:3978 (coerce_template_parms) 15614688: 7.6% 0: 0.0% 882028: 1.3% 519976: 2.4% 528499 cp/name-lookup.c:4293 (arg_assoc_class)20385336:10.0% 0: 0.0% 0: 0.0% 0: 0.0% 849389 Almost all in the front-end. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 16:27:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18835
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 16:32 --- I will need someone to test DCE before FRE for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug tree-optimization/19905] Extra V_MAY_DEF on a static variable whose address is not taken (we should be able to move the load out of the loop)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 16:40 --- I think the FIXME in tree-ssa-operands.c is the answer here: /* FIXME - if we have better information from the static vars analysis, we need to make the cache call site specific. This way we can have the performance benefits even if we are doing good optimization. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19905
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 16:34 --- Confirmed: *a = 1; *b = 2; t = *a; operator delete (a); operator delete (b); return t; -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 16:34:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-23 16:52 --- Could you show what the code looks like before and after FRE? I imagine FRE eliminates one a/b, which isn't really making a mess of loads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 16:53 --- (In reply to comment #2) I imagine FRE eliminates one a/b, which isn't really making a mess of loads. It is eliminating the loads of a and b too but nothing (maybe it is the job of the ra), moves the loads back into the conditional branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug libgcj/23183] SimpleDateFormat fails to render '' as single quotes
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
17:02 ---
Here is the complete test case:
import java.text.*;
import java.util.*;
public class pr23183 {
public static void main(String[] args) {
SimpleDateFormat sdf = new SimpleDateFormat(''-MM-dd HH:mm:ss'');
// Should have quotes around it, but does not.
System.out.println(sdf.format(new Date()));
// should produce ' ' 'FOO' ' '
sdf = new SimpleDateFormat('' '' '''FOO''' '' '');
System.out.println(sdf.format(new Date()));
}
}
This fails with both gcj 4.1 and classpath cvs head (0.17+)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23183
[Bug libstdc++/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 17:13 --- As reported here: http://gcc.gnu.org/ml/gcc-regression/2005-08/msg00040.html This is testsuite problem caused by the update of the address of the FSF. -- What|Removed |Added Component|middle-end |libstdc++ Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23462
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From mattias dot ellert at tsl dot uu dot se 2005-08-23 17:14 --- (In reply to comment #10) Your proposed alternative patch works for me. Both for the testcase in this bug report and when I compile the code I was building when I found the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug fortran/18878] Erronous error message on vaild USE statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-23 17:24
---
I just received this e-mail:
...
Whilst at the airport, I saw a solution to PR18878, whose existence has
bugged me for ages because it looks as if it should be easy. I though
that I would get it to you, via my sister's ISP but cannot do a proper
submit until I am back home (1st Sept). If either of you want to bang
it in, please feel free; it is independent of the other patches. This
works:
! PR18878 example from Steve Kargl
!
module a
integer, parameter :: b = kind(1.e0)
end module a
program d
use a, only : e = b, f = b
real(e) x
real(f) y
x = 1.e0_e
y = 1.e0_f
print *, x, y
end program d
as does this:
module global
real a
end module global
program test_use
use global, only: b=a, c=a
b = 5
if (c /= 5) call abort ()
end program test_use
it regtests fine under Cygwin/Athlon2200M
Best regards
Paul T
PS Cutting and pasting from Cygwin to XP is not good for my head.
Excuses if it is a bit grunged up.
Index: gcc/gcc/fortran/module.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/module.c,v
retrieving revision 1.35
diff -c -p -r1.35 module.c
*** gcc/gcc/fortran/module.c19 Aug 2005 09:05:03 -1.35
--- gcc/gcc/fortran/module.c23 Aug 2005 16:51:57 -
*** cleanup:
*** 585,601
}
! /* Given a name, return the name under which to load this symbol.
!Returns NULL if this symbol shouldn't be loaded. */
static const char *
! find_use_name (const char *name)
{
gfc_use_rename *u;
for (u = gfc_rename_list; u; u = u-next)
! if (strcmp (u-use_name, name) == 0)
! break;
if (u == NULL)
return only_flag ? NULL : name;
--- 588,618
}
! /* Given a name and a number, inst, return the inst name
!under which to load this symbol. Returns NULL if this
!symbol shouldn't be loaded. If inst is zero, returns
!the number of instances of this name. */
static const char *
! find_n_use_name (const char *name, int *inst)
{
gfc_use_rename *u;
+ int i;
+ i = 0;
for (u = gfc_rename_list; u; u = u-next)
! {
! if (strcmp (u-use_name, name) != 0)
! continue;
! if (++i == *inst)
! break;
! }
!
! if (!*inst)
! {
! *inst = i;
! return NULL;
! }
if (u == NULL)
return only_flag ? NULL : name;
*** find_use_name (const char *name)
*** 605,610
--- 622,649
return (u-local_name[0] != '\0') ? u-local_name : name;
}
+ /* Given a name, return the name under which to load this symbol.
+Returns NULL if this symbol shouldn't be loaded. */
+
+ static const char *
+ find_use_name (const char *name)
+ {
+ int i = 1;
+ return find_n_use_name (name, i);
+ }
+
+ /* Given a real name, return the number of use names associated
+with it. */
+
+ static int
+ number_use_names (const char *name)
+ {
+ int i = 0;
+ const char *c;
+ c = find_n_use_name (name, i);
+ return i;
+ }
+
/* Try to find the operator in the current list. */
*** read_module (void)
*** 3020,3026
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_intrinsic_op i;
! int ambiguous, symbol;
pointer_info *info;
gfc_use_rename *u;
gfc_symtree *st;
--- 3101,3107
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_intrinsic_op i;
! int ambiguous, symbol, j, nuse;
pointer_info *info;
gfc_use_rename *u;
gfc_symtree *st;
*** read_module (void)
*** 3084,3133
info = get_integer (symbol);
! /* Get the local name for this symbol. */
! p = find_use_name (name);
!
! /* Skip symtree nodes not in an ONLY caluse. */
! if (p == NULL)
! continue;
!
! /* Check for ambiguous symbols. */
! st = gfc_find_symtree (gfc_current_ns-sym_root, p);
! if (st != NULL)
! {
! if (st-n.sym != info-u.rsym.sym)
! st-ambiguous = 1;
! info-u.rsym.symtree = st;
! }
! else
{
! /* Create a symtree node in the current namespace for this
symbol. */
! st = check_unique_name (p) ? get_unique_symtree (gfc_current_ns) :
! gfc_new_symtree (gfc_current_ns-sym_root, p);
! st-ambiguous = ambiguous;
! sym = info-u.rsym.sym;
! /* Create a symbol node if it doesn't already exist. */
! if (sym == NULL)
{
! sym = info-u.rsym.sym =
! gfc_new_symbol (info-u.rsym.true_name, gfc_current_ns);
!
! sym-module = gfc_get_string (info-u.rsym.module);
}
! st-n.sym = sym;
! st-n.sym-refs++;
! /* Store the symtree pointing to this symbol. */
! info-u.rsym.symtree = st;
! if (info-u.rsym.state == UNUSED)
! info-u.rsym.state = NEEDED;
! info-u.rsym.referenced = 1;
}
}
---
[Bug middle-end/23517] [4.0/4.1 Regression] can't cast between generic vector types and target supported vector types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 17:48 --- Subject: Bug 23517 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 17:48:37 Modified files: gcc: ChangeLog fold-const.c convert.c tree-vect-generic.c Log message: 2005-08-23 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/23517 * fold-const.c (fold_convert): Use VIEW_CONVERT_EXPR to convert between vectors. * convert.c (convert_to_integer, convert_to_vector): Likewise. * tree-vect-generic.c (tree_vec_extract, expand_vector_operations_1): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9810r2=2.9811 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.621r2=1.622 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/convert.c.diff?cvsroot=gccr1=1.67r2=1.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-generic.c.diff?cvsroot=gccr1=2.4r2=2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23517
[Bug middle-end/23517] [4.0/4.1 Regression] can't cast between generic vector types and target supported vector types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 18:01 --- Subject: Bug 23517 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-23 18:01:27 Modified files: gcc: ChangeLog fold-const.c convert.c Log message: 2005-08-23 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/23517 * fold-const.c (fold_convert): Use VIEW_CONVERT_EXPR to convert between vectors. * convert.c (convert_to_integer, convert_to_vector): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.385r2=2.7592.2.386 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.517.2.14r2=1.517.2.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/convert.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.57r2=1.57.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23517
[Bug middle-end/23517] [4.0/4.1 Regression] can't cast between generic vector types and target supported vector types
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23 18:02 --- (note: the tree-vect-generic.c part is not needed on 4.0) Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23517
[Bug rtl-optimization/23524] bigger version of mov + cmp produced
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-23 18:05 --- (In reply to comment #2) You really should know that we only care about code size at -Os. We care about performance regressions though at -O2. Code size is important for performance for modern processors. Small I-cache (and I-TLB) footprint for otherwise equivalent code results in better performance. BTW, this is a 4.1 regression. -- What|Removed |Added OtherBugsDependingO||23153 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
Re: [Bug rtl-optimization/23524] bigger version of mov + cmp produced
On Aug 23, 2005, at 2:06 PM, dann at godzilla dot ics dot uci dot edu wrote: --- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-23 18:05 --- (In reply to comment #2) You really should know that we only care about code size at -Os. We care about performance regressions though at -O2. Code size is important for performance for modern processors. Small I-cache (and I-TLB) footprint for otherwise equivalent code results in better performance. Then use -Os every where instead. You will see that the overall code size for 4.1 has reduced from 4.0. -- Pinski
[Bug rtl-optimization/23524] bigger version of mov + cmp produced
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-23 18:07 --- Subject: Re: bigger version of mov + cmp produced On Aug 23, 2005, at 2:06 PM, dann at godzilla dot ics dot uci dot edu wrote: --- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-23 18:05 --- (In reply to comment #2) You really should know that we only care about code size at -Os. We care about performance regressions though at -O2. Code size is important for performance for modern processors. Small I-cache (and I-TLB) footprint for otherwise equivalent code results in better performance. Then use -Os every where instead. You will see that the overall code size for 4.1 has reduced from 4.0. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug rtl-optimization/23524] bigger version of mov + cmp produced
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-23 18:15 --- (In reply to comment #4) Then use -Os every where instead. You will see that the overall code size for 4.1 has reduced from 4.0. That might be true, but -Os is not always an option. If there's a good reason for -O2 to generate bigger code, then so be it, but that does not seem to be the case for the code in this PR (at least AFAICT). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug java/23431] [4.0/4.1 regression] gcj allows overriding with more restrictive access
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23 18:26 --- I have proposed a patch for this problem: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00266.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00266.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug libstdc++/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail
--- Additional Comments From pcarlini at suse dot de 2005-08-23 18:30 --- Kelley, can you please fix the regression that you introduced? (obviously, you didn't completely regtest the patch). I suggest first padding the new address to the length of the old one with spaces then, in case the checked chars fall inside the address itself, also adjust the checked values to the new ones. In any case, please don't change the size of the file and the various integer constants in the testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23462
[Bug ada/23514] fixed point error cause Ada exception block does NOT work
--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-23 18:42 --- You need a recent GCC 4.1 for this to work as expected, so gcc 3.4 is indeed not expected to work in this case. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23514
[Bug libstdc++/23528] [3.4 Regression] Wrong default allocator in ext/hash_map
--- Additional Comments From pcarlini at suse dot de 2005-08-23 18:23 --- (In reply to comment #11) Thanks a lot. I think adding a proper rebind is the right way to fix the problem, already used in mainline and 4_0-branch, by the way. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|WAITING |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-23 18:56 --- FRE can't really do anything about this. DOM would do the same thing if it was run before DCE. I'll make the sinker sink loads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug fortran/17740] ICE in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2011
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-23 19:54 --- A patch for this bug has been posted to the mailing list: http://gcc.gnu.org/ml/fortran/2005-08/msg00406.html -- What|Removed |Added CC||erik dot edelmann at iki dot ||fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17740
[Bug libgcj/23182] instanceof sometimes fails if compiled with -findirect-dispatch
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
19:58 ---
Reduced test case. Compile to .class, then compile with -findirect-dispatch.
Interpreting works fine.
public class pr23182 {
static class Wrapper {
Object w;
Object get() {
return w;
}
Wrapper(Object x) { w = x; }
}
static Wrapper instance = new Wrapper(null);
public static String toString(Object val) {
for (;;) {
if (val == null)
return null;
if (val instanceof Wrapper) {
val = ((Wrapper) val).get();
if (val != instance val instanceof Wrapper)
throw new RuntimeException(bob);
continue;
}
return val.toString();
}
}
public static void main(String[] args) {
System.out.println(toString(null));
System.out.println(toString(maude));
System.out.println(toString(new Wrapper(liver)));
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-23 20:48
---
So, I fixed another case in which we could die in create_pre_exit having
to do with complex return values. But past that, there are failures that
are completely within optimize_mode_switching, e.g. execute/20050604-1.c.
$ ./cc1 -m32 -march=pentium4 z.c
foo
z.c: In function foo:
z.c:28: error: unable to find a register to spill in class MMX_REGS
z.c:28: error: this is the insn:
(insn 14 63 15 2 (set (reg:V4HI 61 [ D.1620 ])
(mem/s/j:V4HI (symbol_ref:SI (u) var_decl 0x2daff160 u)
[0 u.v+0 S8 A64])) 994 {*movv4hi_internal} (nil)
(nil))
The problem is that we have a CFG like
+--+
v |
1-2-3-4
and we place the efpu insn in block 2, but the emms insn in block 4.
Aside from being Less Than Ideal, this results in BOTH mmx and fpu
registers live around the loop, which means we can't allocate anything.
Uros, you should bootstrap i386 with --with-arch=foo, where foo is
whatever machine you have that supports at least mmx. Otherwise, you're
not actually testing this new code on i386 except for the few test
cases that force an -march or -mmx option.
I'll keep looking at it for a bit to see if its something simple, but
we're not going to overhaul optimize_mode_switching for 4.1 if it's
something complicated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug ada/23519] Dividing fixed point number by zero returns zero.
--- Additional Comments From simon at pushface dot org 2005-08-23 20:55 --- The behaviour with -gnato and without is the same. On the other hand, 'digits 18' fails as shown,'digits 9' gives the exception ... and 'Machine_Overflows is True. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23519
[Bug fortran/23538] New: gfortran hangs on old cray fortran 66 program
gfortan generates hundreds of error on this program then hangs - never to return [dranta:~/tests/gfortran-D] dir% gfortran -o d2ds d2ds.f In file d2ds.f:88 common/ioinfo/jprint,isqsh,ni 1 Warning: Named COMMON block 'ioinfo' at (1) shall be of the same size In file d2ds.f:308 ... ... Error: END DO statement expected at (1) In file d2ds.f:1718 subroutine stravg 1 Error: Unclassifiable statement at (1) ^C [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050823 (experimental) [dranta:~/tests/gfortran-D] dir% -- Summary: gfortran hangs on old cray fortran 66 program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Additional Comments From dir at lanl dot gov 2005-08-23 21:03 --- Created an attachment (id=9570) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9570action=view) old program that hangs gfortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:18 --- Confirmed. gfortran's error reporting and recovery mechanism appears to lead to hopeless confusion within the scanner/parser whereby it gets stuck in an infinite loop. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-23 21:18:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug c++/23539] New: C C++ compiler generating misaligned references regardless of compiler flags
This issue was uncovered in porting our existing software to the GNU tool-
chain. We have a number of structures that contain 3 individual bytes of
data. When the GNU tool-chain compiles the source code, it creates a
load/store byte instruction followed by a load/store half-word instruction with
an odd (1,3,5,7,9,11,etc) memory offset. This causes a data alignment
exception to occur.
We have tried all combinations of the compiler flags for structure packing,
alignment (natural, power), and anything else that we have been able to uncover
in the GCC documentation.
This behavior exists at optimization levels, 0,1 and 2. We haven't tried any
other levels as of yet.
There should be a means of having the compiler override mis-aligned address
references. This is supported at a software level (if the authors of the OS or
software handle this exception). However, the authors of this component did
not, and it would cause far too much of a runtime hit to implement this. A
code sample is included below that will re-create this problem.
File test.cc -
struct foo {
char bar1;
char bar2;
char bar3;
};
int foobarStruct(foo fubarStruct) {
if(fubarStruct.bar1 == 'A'
fubarStruct.bar2 == 'B'
fubarStruct.bar3 == 'C')
{
return 1;
}
else {
return 0;
}
}
int main(int argc, char **argv) {
int rVal1;
int rVal2;
foo barStruct;
barStruct.bar1 = 'A';
barStruct.bar2 = 'B';
barStruct.bar3 = 'C';
rVal1 = foobarStruct(barStruct);
barStruct.bar1 = 'A';
barStruct.bar2 = 'C';
barStruct.bar3 = 'B';
rVal1 = foobarStruct(barStruct);
return (rVal1 || rVal2);
}
- End of file -
Again using any combinations of compiler flags -malign-natural, -malign-power, -
fpack-struct=2, -fno-pack-struct, etc have not given us the desired behavior.
Here's the assembly output from the command(s):
(1) g++ test.cc -o test
(2) ppcobjdump -C -S test.o
test.o: file format elf32-powerpc
Disassembly of section .text:
foobarStruct(foo):
0: 94 21 ff e8 stwur1,-24(r1)
4: 93 e1 00 14 stw r31,20(r1)
8: 7c 3f 0b 78 mr r31,r1
c: 90 7f 00 0c stw r3,12(r31)
10: 81 3f 00 0c lwz r9,12(r31)
14: 88 09 00 00 lbz r0,0(r9)
18: 54 00 06 3e clrlwi r0,r0,24
1c: 2f 80 00 41 cmpwi cr7,r0,65
20: 40 9e 00 38 bne-cr7,58 foobarStruct(foo)+0x58
24: 81 3f 00 0c lwz r9,12(r31)
28: 88 09 00 01 lbz r0,1(r9)
2c: 54 00 06 3e clrlwi r0,r0,24
30: 2f 80 00 42 cmpwi cr7,r0,66
34: 40 9e 00 24 bne-cr7,58 foobarStruct(foo)+0x58
38: 81 3f 00 0c lwz r9,12(r31)
3c: 88 09 00 02 lbz r0,2(r9)
40: 54 00 06 3e clrlwi r0,r0,24
44: 2f 80 00 43 cmpwi cr7,r0,67
48: 40 9e 00 10 bne-cr7,58 foobarStruct(foo)+0x58
4c: 38 00 00 01 li r0,1
50: 90 1f 00 08 stw r0,8(r31)
54: 48 00 00 0c b 60 foobarStruct(foo)+0x60
58: 39 20 00 00 li r9,0
5c: 91 3f 00 08 stw r9,8(r31)
60: 80 1f 00 08 lwz r0,8(r31)
64: 7c 03 03 78 mr r3,r0
68: 81 61 00 00 lwz r11,0(r1)
6c: 83 eb ff fc lwz r31,-4(r11)
70: 7d 61 5b 78 mr r1,r11
74: 4e 80 00 20 blr
0078 main:
78: 94 21 ff a8 stwur1,-88(r1)
7c: 7c 08 02 a6 mflrr0
80: 93 e1 00 54 stw r31,84(r1)
84: 90 01 00 5c stw r0,92(r1)
88: 7c 3f 0b 78 mr r31,r1
8c: 90 7f 00 28 stw r3,40(r31)
90: 90 9f 00 2c stw r4,44(r31)
94: 48 00 00 01 bl 94 main+0x1c
98: 38 00 00 41 li r0,65
9c: 98 1f 00 16 stb r0,22(r31)
a0: 38 00 00 42 li r0,66
a4: 98 1f 00 17 stb r0,23(r31)
a8: 38 00 00 43 li r0,67
ac: 98 1f 00 18 stb r0,24(r31)
b0: 88 1f 00 16 lbz r0,22(r31)
b4: a1 3f 00 17 lhz r9,23(r31)-- Notice the odd offset
b8: 98 1f 00 13 stb r0,19(r31)
bc: b1 3f 00 14 sth r9,20(r31)
c0: 88 1f 00 13 lbz r0,19(r31)
c4: a1 3f 00 14 lhz r9,20(r31)
c8: 98 1f 00 30 stb r0,48(r31)
cc: b1 3f 00 31 sth r9,49(r31)-- Notice the off offset
d0: 38 1f 00 30 addir0,r31,48
d4: 7c 03 03 78 mr r3,r0
d8: 48 00 00 01 bl d8 main+0x60
dc: 7c 60 1b 78 mr r0,r3
e0: 90 1f 00 0c stw r0,12(r31)
e4: 38 00 00 41 li r0,65
e8: 98 1f 00 16 stb r0,22(r31)
ec: 38 00 00 43 li r0,67
f0: 98 1f 00 17 stb r0,23(r31)
f4: 38 00 00 42 li r0,66
f8: 98 1f 00 18 stb r0,24(r31)
fc: 88 1f 00 16 lbz r0,22(r31)
100: a1 3f 00 17 lhz r9,23(r31)-- Again odd offsets
104: 98 1f 00 10 stb r0,16(r31)
108: b1 3f
[Bug target/23539] C C++ compiler generating misaligned references regardless of compiler flags
-- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-23 21:30 --- Actually, I lied about the CFG. It's actually 1-3 with 2-3 still forming the loop. So LCM did the right thing, technically: for the case in which the loop trip count is zero, we avoid the efpu insn. The problem is, the model we have wrt efpu/emms requires that they be used in balanced pairs. And, really, we'd prefer that these insns be pushed out of loops when possible. But I'm not sure how to address this at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:38 --- Can you compile this code with any modern compiler? I used fsplit to split the code into a set of files that contains exactly one subprogram per file. Of the 54 *.f files that I get from fsplit, only 25 of those files can be compiled by g77. Oddly, gfortran can compile 28 of the 54 files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug target/23539] C C++ compiler generating misaligned references regardless of compiler flags
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 21:44 --- I should also mention that the target processor for this is the 603, not 603e or otherwise. Even compiling with the -mtune=603 and -mcpu=603 gives the same output. And those old processors do not handle mis-aligned short references in hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
[Bug target/23539] C C++ compiler generating misaligned references regardless of compiler flags
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 22:24 --- The data access exception is incorrect in this sense. The software developer had updated the status of this issue and states that this causes a Machine Check exception to occur on our current hardware. The observation made earlier that padding the structure with a byte clearing up the issue is still a factual statement. We will have to discuss this with our hardware engineers as to why this occurs, however the issue is the same, since this hardware cannot be modified. The software is for space based satellites which have already been launched. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
[Bug target/23539] C C++ compiler generating misaligned references regardless of compiler flags
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23 22:30 --- GCC assumes you have unaligned access. Use -mstrict-align if you want to assume unaligned access does not work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
[Bug libstdc++/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23 23:05 --- Subject: Bug 23462 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-23 23:05:38 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/testsuite/data: sgetn.txt Log message: 2005-08-23 Kelley Cook [EMAIL PROTECTED] PR libstdc++/23462 * testsuite/data/sgetn.txt: Revert to previous FSF address. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3075r2=1.3076 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/data/sgetn.txt.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23462
