[Bug c++/28540] New: Compile error about using typedefs defined in a template class
/*
In the code snippet below the definition of foo fails with the following error
foo.cc:11: error: expected constructor, destructor, or type conversion before
A
But the definition of foo2 triggers no error. I think both should be compiled
but it might be a language idiosyncrasy. Thanks.
*/
template
class A
{
public:
typedef int blah;
blah foo();
blah foo2();
};
template
A::blah A::foo()
{
return 0;
}
template
A::blah A::foo2()
{
return 1;
}
--
Summary: Compile error about using typedefs defined in a template
class
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peaceout2324 at yahoo dot com
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28540
[Bug c++/28541] New: Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
I got a segmentation fault when trying to compile the GDAL library. Here is the result of compiling the preprocessed source: gdal_crs.c: In function 'calccoef': gdal_crs.c:700: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . A workaround is to disable optimization. I couldn't find how to upload the source in bugzilla so I put it on my server: http://rigel.johome.net/gdal_crs.i -- Summary: Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: henrik at johome dot net GCC build triplet: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28541
[Bug c++/28542] New: Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
I got a segmentation fault when trying to compile the GDAL library. Here is the result of compiling the preprocessed source: gdal_crs.c: In function 'calccoef': gdal_crs.c:700: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . A workaround is to disable optimization. -- Summary: Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: henrik at johome dot net GCC build triplet: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
[Bug c++/28542] Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
--- Comment #1 from henrik at johome dot net 2006-07-30 09:09 --- Created an attachment (id=11970) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11970&action=view) Source of the file that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
[Bug c++/28541] Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
--- Comment #1 from henrik at johome dot net 2006-07-30 09:15 --- *** This bug has been marked as a duplicate of 28542 *** -- henrik at johome dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|Segmentation fault using gcc|Segmentation fault using gcc |(v4.0.3) in Ubuntu Dapper |(v4.0.3) in Ubuntu Dapper http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28541
[Bug c++/28542] Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
--- Comment #2 from henrik at johome dot net 2006-07-30 09:15 --- *** Bug 28541 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
[Bug c++/28543] New: Usage of -ftemplate-depth- may cause segfault
$ cat fac.cpp
#include
template struct f;
template<> struct f<0> { enum { value = 1 }; };
template<> struct f<1> { enum { value = 1 }; };
template struct f { enum { value = n * f::value }; };
int main()
{
printf("%u\n", f<-10>::value);
return 0;
}
$ LANG=en_EN g++ -ftemplate-depth-1 fac.cpp
g++: Internal error: Segmentation fault (program cc1plus)
--
Summary: Usage of -ftemplate-depth- may cause segfault
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28543
[Bug c++/28540] Compile error about using typedefs defined in a template class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 09:49 ---
You want:
template
typename A::blah A::foo()
{
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28540
[Bug c++/28543] Usage of -ftemplate-depth- may cause segfault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 09:53 --- This is the whole point of -ftemplate-depth is to limit the depth so you don't run into an huge depth. Yes you code is defined, just a huge depth. *** This bug has been marked as a duplicate of 27052 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28543
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-30 09:53 --- *** Bug 28543 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dushistov at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c++/28539] granted access to private nested class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 10:24 --- *** This bug has been marked as a duplicate of 25863 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28539
[Bug c++/25863] Allowed knowledge of private structure.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 10:24 --- *** Bug 28539 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dushistov at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25863
[Bug middle-end/28542] Segmentation fault using gcc (v4.0.3) in Ubuntu Dapper
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 10:28 --- Can you show the command line which you used to invoke gcc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|Configured with:|x86_64-linux-gnu |../src/configure -v -- | |enable-languages=c,c++,ja | GCC host triplet|gcc version 4.0.3 (Ubuntu |x86_64-linux-gnu |4.0.3-1ubuntu5) | Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
internal ld error building gcc 4.2 (20060729) snapshot on i386 Centos 4.3
I've logged a binutils bug for this as bug id 2979. There is more info with the binutils bug report. I've been able to build older snapshots on this system. [EMAIL PROTECTED] objdir]# ../gcc-4.2-20060513/configure --prefix=/usr/local/gcc-4.2 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --host=i386-redhat-linux --enable-languages=c,c++,fortran --program-suffix=42 --disable-libgcj [EMAIL PROTECTED] objdir]# make bootstrap ...snip... /bin/sh ../libtool --tag CXX --mode=link /root/objdir/./gcc/xgcc -shared-libgcc -B/root/objdir/./gcc -nostdinc++ -L/root/objdir/i386-redhat-linux/libstdc++-v3/src -L/root/objdir/i386-redhat-linux/libstdc++-v3/src/.libs -B/usr/local/gcc-4.2/i386-redhat-linux/bin/ -B/usr/local/gcc-4.2/i386-redhat-linux/lib/ -isystem /usr/local/gcc-4.2/i386-redhat-linux/include -isystem /usr/local/gcc-4.2/i386-redhat-linux/sys-include -Wl,-O1 -Wl,-z,relro -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /usr/local/gcc-4.2/lib -version-info 6:9:0 -Wl,--version-script=libstdc++-symbols.ver -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm /root/objdir/./gcc/xgcc -shared-libgcc -B/root/objdir/./gcc -nostdinc++ -L/root/objdir/i386-redhat-linux/libstdc++-v3/src -L/root/objdir/i386-redhat-linux/libstdc++-v3/src/.libs -B/usr/local/gcc-4.2/i386-redhat-linux/bin/ -B/usr/local/gcc-4.2/i386-redhat-linux/lib/ -isystem /usr/local/gcc-4.2/i386-redhat-linux/include -isystem /usr/local/gcc-4.2/i386-redhat-linux/sys-include -shared -nostdlib /usr/lib/crti.o /root/objdir/./gcc/crtbeginS.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive -L/root/objdir/i386-redhat-linux/libstdc++-v3/src -L/root/objdir/i386-redhat-linux/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm -L/root/objdir/./gcc -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s /root/objdir /./gcc/crtendS.o /usr/lib/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,--version-script=libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.9/usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at ../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 make[4]: Leaving directory `/root/objdir/i386-redhat-linux/libstdc++-v3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/objdir/i386-redhat-linux/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/objdir/i386-redhat-linux/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/root/objdir' make: *** [bootstrap] Error 2 Andrew Roberts
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-30 10:52 --- Please ping the patch. Add DJ Delorie to the CC: list, he is a build system maintainer. You can find his email in MAINTAINERS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug target/28126] gcc moves an expensive instruction outside of a conditional
--- Comment #8 from rsandifo at gcc dot gnu dot org 2006-07-30 10:56 --- Subject: Bug 28126 Author: rsandifo Date: Sun Jul 30 10:56:07 2006 New Revision: 115819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115819 Log: gcc/ 2006-07-25 Atsushi Nemoto <[EMAIL PROTECTED]> PR target/28126 (partial fix) * config/mips/mips.md (tls_get_tp_): Set can_delay to no. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
[Bug middle-end/28473] [4.0 Regression] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #11 from sayle at gcc dot gnu dot org 2006-07-30 13:22 --- Subject: Bug 28473 Author: sayle Date: Sun Jul 30 13:21:59 2006 New Revision: 115821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115821 Log: PR middle-end/28473 Backport from mainline. * convert.c (convert_to_integer): When transforming (T)foo(x) into bar(x) check that bar's result type can represent all the values of T. * builtins.c (fold_fixed_mathfn): When long and long long are the same size, canonicalize llceil*, llfloor*, llround* and llrint* functions to their lceil*, lfloor*, lround* and lrint* forms. * gcc.dg/fold-convround-1.c: New test case. * gcc.dg/builtins-55.c: New test case. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/builtins-55.c branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/fold-convround-1.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/convert.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug middle-end/28473] [4.0 Regression] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-30 13:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-30 13:35 --- Created an attachment (id=11971) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11971&action=view) Use alternative algorithm if it gives better results New algorithm lives in separate function gcc_fastdiv_params() which is called from choose_multiplier(). Then we run old algorithm. Then we compare results and if new algorithm gives different one (new result is always better or same than old), we use it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #5 from vda dot linux at googlemail dot com 2006-07-30 13:37 --- Created an attachment (id=11972) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11972&action=view) Test program Compile with -O2 -S to see the assembly. Compile with -Os and run to check the correctness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #6 from vda dot linux at googlemail dot com 2006-07-30 13:38
---
Patched versus stock gcc-4.1.1 on this code
unsigned v;
void f9188_mul365384439_shift27(unsigned A) { v = A/(unsigned)1577682821; }
is:
# diff -u suboptimal-411-O2.s suboptimal-411-O2-fixed.s
--- suboptimal-411-O2.s 2006-07-29 19:34:09.0 +0200
+++ suboptimal-411-O2-fixed.s 2006-07-29 19:37:14.0 +0200
@@ -19,21 +19,10 @@
f9188_mul365384439_shift27:
pushl %ebp
movl%esp, %ebp
- pushl %edi
- pushl %esi
- pushl %ebx
- movl8(%ebp), %ebx
- movl$1551183727, %ecx
- movl%ebx, %eax
- mull%ecx
- subl%edx, %ebx
- shrl%ebx
- leal(%ebx,%edx), %eax
- shrl$30, %eax
- movl%eax, v
- popl%ebx
- popl%esi
- popl%edi
+ movl$365384439, %eax
+ mull8(%ebp)
+ shrl$27, %edx
+ movl%edx, v
leave
ret
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-30 13:43 --- Created an attachment (id=11973) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11973&action=view) Random tester Randomly chooses a/b and compares "gcc patch code" results with code which was previously verified to be ok. Just my internal tool to check that I did not screw up while making a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug tree-optimization/28544] New: [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
I get the following gcc 4.2 regression:
11031:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
mysql-sp_cache.cc
mysql-sp_cache.cc: In function 'void sp_cache_invalidate()':
mysql-sp_cache.cc:20: internal compiler error: in add_virtual_operand, at
tree-ssa-operands.c:1309
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
11032:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O
mysql-sp_cache.cc
11033:[EMAIL PROTECTED]: ~] g++-4.1 -c -O2 mysql-sp_cache.cc
11034:[EMAIL PROTECTED]: ~] g++-4.0 -c -O2 mysql-sp_cache.cc
11035:[EMAIL PROTECTED]: ~] cat mysql-sp_cache.cc
extern "C"
{
extern "C"
{
typedef unsigned long int ulong;
}
typedef struct
{
volatile int counter;
}
atomic_t;
static __inline__ void atomic_inc (atomic_t * v)
{
__asm__ __volatile__ ("lock ; "
"incl %0":"=m" (v->counter):"m" (v->counter));
}
}
static ulong volatile Cversion = 0;
void
sp_cache_invalidate ()
{
atomic_inc ((atomic_t *) & Cversion);
}
--
Summary: [4.2 regression] ICE in add_virtual_operand, at tree-
ssa-operands.c:1309
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-30 13:53 --- First I like to say this is violating C++ aliasing rules but that is a different story. Second this is most likely a dup of bug 28479. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28479 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #2 from tbm at cyrius dot com 2006-07-30 13:55 --- (In reply to comment #1) > First I like to say this is violating C++ aliasing rules but that is a > different story. > > Second this is most likely a dup of bug 28479. Are you sure you got that bug number right? I'm seeing this ICE not just with current 4.2 but also from many months ago (will try to narrow down a date in a minute). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #3 from tbm at cyrius dot com 2006-07-30 13:59 --- Reproducible with gcc 4.2.0 way back to 20060325. I've nothing older around right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-07-30 14:04
---
(In reply to comment #28)
> I've been trying to figure out why we end up with the strange intialization
> for
> the
> parity loop. I see this rtl in the loop2 dump:
>
> (jump_insn 69 68 71 7 (set (pc)
> (if_then_else (ne (reg/v:SI 109 [ i ])
> (reg:SI 130))
> (label_ref 27)
> (pc))) 25 {*pa.md:1710} (nil)
> (expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
> (const_int 64 [0x40]))
> (label_ref 27)
> (pc))
> (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
> (nil
> ;; End of basic block 7, registers live:
> (nil)
> This gets transformed to the following rtl in the loop2_init dump:
> (jump_insn 69 68 116 7 (set (pc)
> (if_then_else (ne (reg/v:SI 109 [ i ])
> (reg:SI 130))
> (label_ref:SI 116)
> (pc))) -1 (nil)
> (expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
> (const_int 64 [0x40]))
> (label_ref:SI 116)
> (pc))
> (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
> (nil
> ;; End of basic block 7, registers live:
> (nil)
>
> ;; Start of basic block 13, registers live: (nil)
> (code_label 116 69 115 13 55 "" [1 uses])
>
> (note 115 116 71 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
> ;; End of basic block 13, registers live:
> (nil)
> As a result, jump_insn 69 no longer does anything. All references
> to code_label 27 are now gone and this appears to allow stuff that
> was originally in the loop to end up as a loop initializers.
no, this seems correct to me. In cfglayout mode (that is used in the loop
optimizations), the unconditional jumps are removed and they are represented
only implicitly by edges in the cfg. BB 13 is probably a forwarder block
created by some of the loop shape canonicalization transformations, and its
single successor is the block containing label 27 (i.e., bb 13 implicitly
contains (jump_insn (set (pc) (label_ref 27)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-30 14:26 --- Oh, yes it is unrelated to that PR. In fact I think the aliasing violating causes the problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn|28479 | Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-30 14:44 ---
Confirmed (reduced C and C++ testcases:
typedef unsigned long int ulong;
typedef struct
{
volatile int counter;
}atomic_t;
static ulong volatile Cversion = 0;
void
sp_cache_invalidate ()
{
atomic_t * v1 = (atomic_t *)& Cversion;
atomic_t * v = v1;
__asm__ __volatile__ ("lock ; incl %0":"=m" (v->counter):"m" (v->counter));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-07-30 14:44:23
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-30 14:45 ---
Even without the volatile, it ICEs:
typedef unsigned long int ulong;
typedef struct
{
int counter;
}atomic_t;
static ulong Cversion = 0;
void
sp_cache_invalidate ()
{
atomic_t * v1 = (atomic_t *)& Cversion;
atomic_t * v = v1;
__asm__ __volatile__ ("lock ; incl %0":"=m" (v->counter):"m" (v->counter));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug c/28545] New: Wrong code for hoisted multiplication
I have some code that calls memset(p, cr+1, cr*cr); inside a loop. (Will attach this later.) gcc 4.1.2 (snapshot from 20060715) appears to attempt to calculate cr*cr outside the loop and then load it when needed. However, the generated code uses the wrong register for one the multiplicands: movl%edi, %ecx /* edi contains cr */ xorl%eax, %eax imull %ebx, %ecx /* ebx contains another variable */ leal1(%edi), %ebx -- Summary: Wrong code for hoisted multiplication Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ben at decadentplace dot org dot uk GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug c/28545] Wrong code for hoisted multiplication
--- Comment #1 from ben at decadentplace dot org dot uk 2006-07-30 18:46 --- Created an attachment (id=11974) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11974&action=view) test case Test case. It should produce the output "Difficulty rating: Extreme (complex non-recursive techniques required)". When compiled and run on i486-linux-gnu with -O2 it seg-faults in memset() due to a wrong length value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug libgcj/28546] New: ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
/xxx/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/xxx/gnu/gcc/objdir/./gcc -nostd inc++ -L/xxx/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/libstdc++-v3/src -L/xxx/gnu/gc c/objdir/hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs -B/opt/gnu/gcc/gcc-4.2.0/h ppa2.0w-hp-hpux11.00/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.00/lib/ -i system /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.00/include -isystem /opt/gnu/gc c/gcc-4.2.0/hppa2.0w-hp-hpux11.00/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc /libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude -I../../../gcc/lib java/include -I../../../gcc/libjava/classpath/include -Iclasspath/include -I../. ./../gcc/libjava/classpath/native/fdlibm -I../../../gcc/libjava/../boehm-gc/incl ude -I../boehm-gc/include -I../../../gcc/libjava/libltdl -I../../../gcc/libjava/ libltdl -I../../../gcc/libjava/.././libjava/../gcc -I../../../gcc/libjava/../zli b -I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-c all-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -We xtra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gnu/gcc/gcc-4.2.0\" -DLIBDIR=\"/opt/gnu /gcc/gcc-4.2.0/lib\" -DJAVA_HOME=\"/opt/gnu/gcc/gcc-4.2.0\" -DBOOT_CLASS_PATH=\" /opt/gnu/gcc/gcc-4.2.0/share/java/libgcj-4.2.0.jar\" -DJAVA_EXT_DIRS=\"/opt/gnu/ gcc/gcc-4.2.0/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/opt/gnu/gcc/gcc-4.2.0/shar e/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/opt/gnu/gcc/gcc-4.2.0/lib/gcj-4. 2.0\" -DPATH_SEPARATOR=\":\" -DLIBGCJ_DEFAULT_DATABASE=\"/opt/gnu/gcc/gcc-4.2.0/ lib/gcj-4.2.0/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.2.0/clas smap.db\" -DTOOLEXECLIBDIR=\"/opt/gnu/gcc/gcc-4.2.0/lib\" -g -O2 -MT prims.lo -M D -MP -MF .deps/prims.Tpo -c ../../../gcc/libjava/prims.cc -fPIC -DPIC -o .libs /prims.o ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' ./include/java-threads.h:28: error: '_Jv_Thread_t' has a previous declaration he re make[3]: *** [prims.lo] Error 1 Thread.h: ... class _Jv_JNIEnv; class _Jv_Thread_t; #define _JV_NOT_OWNER 1 ... java-threads.h: ... typedef int _Jv_Mutex_t; typedef int _Jv_Thread_t; typedef void _Jv_ThreadStartFunc (java::lang::Thread *); ... -- Summary: ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.00 GCC host triplet: hppa2.0w-hp-hpux11.00 GCC target triplet: hppa2.0w-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|./java/lang/Thread.h:31:|[4.2 Regression] |error: using typedef-name |./java/lang/Thread.h:31: |'_Jv_Thread_t' after 'class'|error: using typedef-name ||'_Jv_Thread_t' after 'class' Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug middle-end/28545] Wrong code for hoisted multiplication
--- Comment #2 from ben at decadentplace dot org dot uk 2006-07-30 19:02 --- This code appears to be compiled correctly with a 2006-07-21 snapshot. This doesn't necessarily mean the underlying bug has gone away, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/28545] [4.1 only] Wrong code for hoisted multiplication
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-30 19:05 --- This works on the mainline. I can reproduce it on the 4.1 branch though. I don't know if this is a regression or not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 Known to work||4.2.0 Summary|Wrong code for hoisted |[4.1 only] Wrong code for |multiplication |hoisted multiplication Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/28545] [4.1 only] Wrong code for hoisted multiplication
--- Comment #4 from ben at decadentplace dot org dot uk 2006-07-30 20:11 --- Works on a 2006-02-18 snapshot of 4.2 Fails on a 2005-11-24 snapshot of 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #1 from andreast at gcc dot gnu dot org 2006-07-30 20:21 --- This is in include/no-threads.h. So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or posix threads are not supported here. Just for the record, hppa2.0w-hp-hpux11.11 does work. If the first is the case, we have to investigate why. If the second is the case, we have to adapt include/no-threads.h to match the compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
--- Comment #5 from echristo at gcc dot gnu dot org 2006-07-30 20:50 --- Subject: Bug 27543 Author: echristo Date: Sun Jul 30 20:50:00 2006 New Revision: 115827 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115827 Log: 2006-07-30 Eric Christopher <[EMAIL PROTECTED]> PR target/27543 * doc/extend.texi (i386 Variable Attributes): Add anchor. (PowerPC Variable Attributes): New section. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
--- Comment #6 from echristo at apple dot com 2006-07-30 20:50 --- Fixed thusly: 2006-07-30 Eric Christopher <[EMAIL PROTECTED]> PR target/27543 * doc/extend.texi (i386 Variable Attributes): Add anchor. (PowerPC Variable Attributes): New section. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-30 20:51 --- Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' > This is in include/no-threads.h. Ah, that's correct since I see I specified '--enable-threads=single'. I was going to work further on the _REENTRANT problem but lost track of this fact. In any event, we didn't used to hit this problem. The forward declaration in Makefile.am seems like a hack. > So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or > posix threads are not supported here. > > Just for the record, hppa2.0w-hp-hpux11.11 does work. Probably not if configured with '--enable-threads=single'. This is the default on hpux11. POSIX threads are always available, so possibly we should just force posix threads. On the otherhand, I'm still thinking that I would like '--enable-threads=single' to work for hpux10. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
Re: [Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-30 20:51 --- Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' This is in include/no-threads.h. Ah, that's correct since I see I specified '--enable-threads=single'. I was going to work further on the _REENTRANT problem but lost track of this fact. In any event, we didn't used to hit this problem. The forward declaration in Makefile.am seems like a hack. So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or posix threads are not supported here. Just for the record, hppa2.0w-hp-hpux11.11 does work. Probably not if configured with '--enable-threads=single'. This is the default on hpux11. POSIX threads are always available, so possibly we should just force posix threads. On the otherhand, I'm still thinking that I would like '--enable-threads=single' to work for hpux10. Right and right, and I think it is platform independent. If one uses --enable-threads=single on any platform we will hit this compilation problem. So, the right way to solve this is to attack the include/no-threads.h place.
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #3 from toa at pop dot agri dot ch 2006-07-30 21:06 --- Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-30 > 20:51 --- > Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using > typedef-name '_Jv_Thread_t' after 'class' > >> This is in include/no-threads.h. > > Ah, that's correct since I see I specified '--enable-threads=single'. > I was going to work further on the _REENTRANT problem but lost track > of this fact. > > In any event, we didn't used to hit this problem. The forward > declaration in Makefile.am seems like a hack. > >> So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or >> posix threads are not supported here. >> >> Just for the record, hppa2.0w-hp-hpux11.11 does work. > > Probably not if configured with '--enable-threads=single'. This is > the default on hpux11. POSIX threads are always available, so possibly > we should just force posix threads. On the otherhand, I'm still > thinking that I would like '--enable-threads=single' to work for hpux10. Right and right, and I think it is platform independent. If one uses --enable-threads=single on any platform we will hit this compilation problem. So, the right way to solve this is to attack the include/no-threads.h place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-07-30 21:38 --- Created an attachment (id=11975) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11975&action=view) Latest version Fixed a bunch of problems, added some documentation, and moved MOVE_ALLOC to a file of it's own. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-30 22:46 --- (In reply to comment #2) > I'm an absolute beginner in programming gfortran, but the following > patch seems to solve this bug by inserting an if-block into the code > in order to prevent the access to the NULL pointer in case the array > is pointing to NULL. Alexander, Thanks for the patch, but I think it is only covering up the real problem. It's more a question of "why is it a NULL pointer?" not whether we can work around the NULL pointer. I suspect that some where in resolve.c, gfortran is not properly setting/propagating information about optional arguments and entry statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug debug/28547] New: Large compile time regression with -g
The attached code shows a large (between 2x and 10x) increase in compile time when compiled with -g. With gcc head "-g -O" -ftime-report says: symout: 14.26 (59%) usr 0.09 (24%) sys 15.35 (59%) wall 13879 kB (17%) ggc variable tracking : 0.86 ( 4%) usr 0.03 ( 8%) sys 0.89 ( 3%) wall 28140 kB (34%) ggc With gcc 4.1 even larger slowdowns are also observable with "-O2 -g" and "-O2 -g -fomit-frrame-pointer". These don't seem to occur with head -- Summary: Large compile time regression with -g Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pbrook at gcc dot gnu dot org GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
[Bug debug/28547] Large compile time regression with -g
--- Comment #1 from pbrook at gcc dot gnu dot org 2006-07-30 22:53 --- Created an attachment (id=11976) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11976&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
[Bug fortran/28335] [4.1 only] flush() / write() statement on closed units - error?
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-30 23:12 --- Shame on us for following the gut feeling instead of the Standard. As Steve Kargl pointed out on the mailing list: F95 standard, Section 9.3.5, page 143, lines 6 an 7. Execution of a CLOSE statement specify a unit that does not exit or has no file connected to it is permitted and affects no file. F2003 has the exact same text. Seems we have a regression. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28335] [4.1 only] flush() / write() statement on closed units - error?
-- steven 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|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
-- steven at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[4.1 only] flush() / write()|[4.2 Regression] flush() / |statement on closed units - |write() statement on closed |error? |units - error? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28548] New: [4.2 Regression]: Optional argument failed
This is extracted from Tonto in SPEC CPU 2006: [EMAIL PROTECTED] cpu2006-465g]$ cat foo.f90 SUBROUTINE foo(p, translate) real(kind=kind(1.0d0)), dimension(3) :: p integer(kind=kind(1)), dimension(3), optional :: translate if (present(translate)) p = p + translate END SUBROUTINE [EMAIL PROTECTED] cpu2006-465g]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S foo.f90 In file foo.f90:4 if (present(translate)) p = p + translate 1 Error: 'translate' at (1) is an array and OPTIONAL; it cannot therefore be an actual argument of an ELEMENTAL procedure unless there is a non-optional argument with the same rank (12.4.1.5) make: *** [foo.s] Error 1 [EMAIL PROTECTED] cpu2006-465g]$ -- Summary: [4.2 Regression]: Optional argument failed Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto correctly
--- Comment #23 from hjl at lucon dot org 2006-07-30 23:27 --- Tonto failed to build again. -- hjl at lucon dot org changed: What|Removed |Added BugsThisDependsOn||28548 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug fortran/28548] [4.2 Regression]: Optional argument failed
--- Comment #1 from hjl at lucon dot org 2006-07-30 23:29 --- It is caused by http://gcc.gnu.org/ml/fortran/2006-07/msg00115.html -- hjl at lucon dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
[Bug fortran/28548] [4.2 Regression]: Optional argument failed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-30 23:53 --- >From reading the error message, it looks correct as the types are different. HJL can you first read the pointed to part of the standard and see if this is true if so then gfortran is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-07-31 00:09 --- Subject: Bug 28335 Author: jvdelisle Date: Mon Jul 31 00:09:16 2006 New Revision: 115828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115828 Log: 2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/28335 * gfortran.dg/no_unit_error_1.f90: Delete test. * gfortran.dg/no_unit_error_2.f90: Delete test. Removed: trunk/gcc/testsuite/gfortran.dg/no_unit_error_1.f90 trunk/gcc/testsuite/gfortran.dg/no_unit_error_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-07-31 00:15 --- Subject: Bug 28335 Author: jvdelisle Date: Mon Jul 31 00:15:08 2006 New Revision: 115829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115829 Log: 2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/28335 * close.c (st_close): Revert previous patch and add comment. * file_position.c (st_flush): Revert previous patch and add comment. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/close.c trunk/libgfortran/io/file_pos.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28548] [4.2 Regression]: Optional argument failed
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-31 00:23 --- Andrew, I think it is a bug. The language in section 12.4.1.5 is somewhat convoluted and the description of PRESENT() suggest that PRESENT is special. >From 12.4.1.5: An optional dummy argument that is not present is subject to the following restrictions: (3) It shall not be supplied as an actual argument corresponding to a nonoptional dummy argument other than as the argument of the PRESENT intrinsic function. (5) If it is an array, it shall not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. 13.14.82 PRESENT (A) Description. Determine whether an optional argument is present. Class. Inquiry function. Argument.'A' shall be the name of an optional dummy argument that is accessible in the subprogram in which the PRESENT function reference appears. It may be of any type and it may be a pointer. It may be scalar or array valued. It may be a dummy procedure. The dummy argument 'A' has no INTENT attribute. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #10 from gnb at sgi dot com 2006-07-31 01:18 --- Ian: understood and agreed. FYI: the copyright assignment arrived in this morning's mail. I'll need to run it past my lawyer (as I do any legal document) but I don't expect that will take long. The bottleneck is likely to be the employer disclaimer, which will need to go back across the Pacific and up through some layers of corporate bureaucracy. I assume you need both before I can post? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:32 --- Subject: Bug 28335 Author: jvdelisle Date: Mon Jul 31 01:32:38 2006 New Revision: 115835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115835 Log: 2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/28335 * file_position.c (st_flush): Add clearer error when UNIT does not exist. Add reference to standard in comment. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:36 --- Subject: Bug 28335 Author: jvdelisle Date: Mon Jul 31 01:36:44 2006 New Revision: 115836 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115836 Log: 2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/28335 * gfortran.dg/no_unit_error_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/no_unit_error_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug middle-end/28545] [4.1 only] Wrong code for hoisted multiplication
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-31 01:41 --- I wonder if this is a memset only problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-07-31 01:57 --- Subject: Bug 28335 Author: jvdelisle Date: Mon Jul 31 01:57:25 2006 New Revision: 115837 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115837 Log: 2006-07-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/28335 * close.c (st_close): Revert error when UNIT does not exist. Add comment to reference standard. * file_position.c (st_flush): Improve error message. Add comment to reference standard. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/close.c branches/gcc-4_1-branch/libgfortran/io/file_pos.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28335] [4.2 Regression] flush() / write() statement on closed units - error?
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-07-31 02:02 --- Fixed on 4.1 and 4.2. Please accept my apologies. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-31 02:09 --- Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointeRO > no, this seems correct to me. In cfglayout mode (that is used in the loop > optimizations), the unconditional jumps are removed and they are represented > only implicitly by edges in the cfg. BB 13 is probably a forwarder block > created by some of the loop shape canonicalization transformations, and its > single successor is the block containing label 27 (i.e., bb 13 implicitly > contains (jump_insn (set (pc) (label_ref 27))) Ok, I've learned something new about RTL. Looking some more, I think the bug is in the cse2 pass. In particular, the substitution of reg:SI 138 for reg:SI 176 appears wrong. Before this pass, the most significant 32 bits of the long long were arithmetically shifted (ashift) first by 1 and then -1 when i is 0. The latter shift is equivalent to a shift of 31 because of the modulo nature of shifting on this target. Thus, reg:SI 176 should be 0 when i is 0. However, the cse2 substitution or's in the most significant 32-bits of the original long long into the least significant 32 bits of reg:DI 113. This results in bit 31 being counted twice. For some reason, this substitution doesn't happen in my_parityll. There are some differences in the unrolling in main and my_parityll. For example, I see this in the output for main: Loop 2 is simple: simple exit 7 -> 8 number of iterations: (plus:SI (not:SI (reg/v:SI 109 [ i ])) (reg:SI 142)) upper bound: -1 Whereas, for my_parityll: Loop 1 is simple: simple exit 6 -> 7 number of iterations: (const_int 63 [0x3f]) upper bound: 63 Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #4 from taschna at uni-muenster dot de 2006-07-31 06:32 ---
(In reply to comment #3)
Steve,
> Thanks for the patch, but I think it is only covering up the real
> problem. It's more a question of "why is it a NULL pointer?" not
> whether we can work around the NULL pointer. I suspect that some
> where in resolve.c, gfortran is not properly setting/propagating
> information about optional arguments and entry statements.
looking at the dump of the original tree below I would say that
it is okay to have the arguments n and vector equal NULL in
case of the call from nranin. The main problem is the code
emitted by gfc_trans_g77_array before the entry master switch.
The best solution in my opionion would be to emit the code in
the block following label L.2, but I didn't know how to do
this. Therefore I propose to do the same as we do in
gfc_trans_dummy_array_bias since revision 86128 (committed by Paul Brook)
and emit an if block surrounding the offending code.
---
MAIN__ ()
{
_gfortran_set_std (70, 127, 0);
{
real4 C.687 = 5.4321e+4;
nranin (&C.687);
}
nran (vector, n)
{
master.0.nran (0, 0B, n, vector);
nranin (v)
{
master.0.nran (1, v, 0B, 0B);
master.0.nran (__entry, v, n, vector)
{
int4 i;
int4 ubound.0;
int4 size.1;
int4 D.723;
bit_size_type D.724;
D.725;
ubound.0 = *n;
size.1 = NON_LVALUE_EXPR ;
D.723 = size.1 - 1;
D.724 = (bit_size_type) () size.1 * 32;
D.725 = () size.1 * 4;
switch (__entry)
{
case 0:;
goto L.2;
case 1:;
goto L.4;
}
L.2:;
{
int4 D.716;
D.716 = *n;
i = 1;
if (i <= D.716)
{
while (1)
{
{
logical4 D.720;
(*vector)[NON_LVALUE_EXPR + -1] = rndm (&i);
L.5:;
D.720 = i == D.716;
i = i + 1;
if (D.720) goto L.6; else (void) 0;
}
}
}
else
{
(void) 0;
}
L.6:;
}
goto __return_master.0.nran;
L.4:;
rdmin (v);
goto __return_master.0.nran;
__return_master.0.nran:;
}
rdmin (v)
{
(void) 0;
rndm (i)
{
real4 __result_rndm;
__result_rndm = (real4) *i;
return __result_rndm;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
