[Bug rtl-optimization/15439] ICE with -fschedule-insns2 -fsched2-use-traces
--- Comment #4 from uros at kss-loka dot si 2005-11-11 08:20 --- This is in fact duplicate of PR 19340. Fixed in 3.4.5. *** This bug has been marked as a duplicate of 19340 *** -- uros at kss-loka dot si changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.0 |4.0.0 3.4.5 Resolution||DUPLICATE Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15439
[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #10 from uros at kss-loka dot si 2005-11-11 08:20 --- *** Bug 15439 has been marked as a duplicate of this bug. *** -- uros at kss-loka dot si changed: What|Removed |Added CC||coyote at coyotegulch dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug c/24788] New: getting complier error:Internal compiler error in ix86_attr_length_immediate_default
Hello, We are uprading gcc 2.95 to gcc 3.2.2 in Lynxos on x86. We have given the configration has :- --host=$(HOST) --target=$(TARGET) \ --prefix=$(PREFIX) \ --program-prefix= \ --enable-languages=c \ --disable-nls then we gave make all We are getting following error: /toolchain/src/gcc/crtstuff.c: In function `__do_global_dtors_aux': /toolchain/src/gcc/crtstuff.c:286: , at config/i386/i386.c:9967 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make: *** [crtbegin.o] Error 1 -- Summary: getting complier error:Internal compiler error in ix86_attr_length_immediate_default Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: basavaraja_g at mindtree dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24788
[Bug fortran/24789] New: [gfortran] ICE when assigning to array of strings
Current mainline gfortran ICEs on the following code: subroutine foo(vals) character(len = *), pointer :: vals(:) vals = '' end subroutine [EMAIL PROTECTED]:~/tmp gfortran -v test.F90 Driving: gfortran -v test.F90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --quiet --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran Thread model: posix gcc version 4.1.0 2005 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.1.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v test.F90 -mtune=k8 -o /tmp/ccchY9YK.f95 ignoring nonexistent directory /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/martin/software/ugcc/include /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.0/include /usr/include End of search list. /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.1.0/f951 /tmp/ccchY9YK.f95 -quiet -dumpbase test.F90 -mtune=k8 -auxbase test -version -o /tmp/ccaQr9Uk.s GNU F95 version 4.1.0 2005 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.1.0 2005 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 test.F90: In function foo: test.F90:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The Fortran compiler from the GOMP branch does not ICE on this code. This ICE may be related to PR24266, but I'm not absolutely sure, and anyway, my testcase is shorter :) -- Summary: [gfortran] ICE when assigning to array of strings Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24789
[Bug libfortran/24787] [libfortran] SCAN is broken
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-11 08:42 --- Man, I love the easy ones. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00803.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24787
[Bug inline-asm/23200] [4.0/4.1 regression] rejects i(var + 1)
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-11-11 08:59
---
Could the patch to lower pointer arithmetic to array arithmetic help?
typedef int int_array[];
typedef int_array *p_int_array;
int var;
void f()
{
asm volatile ( :: i((*(p_int_array)var)[1]));
}
does not work too, but it looks like if the compiler did this lowering, it
would be valid GIMPLE and there would be no need to create the temporary.
And this would be doable at -O0 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug inline-asm/23200] [4.0/4.1 regression] rejects i(var + 1)
--- Comment #12 from bonzini at gcc dot gnu dot org 2005-11-11 09:00 --- CCing dberlin as he was the author of the pointer-array patch. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug fortran/24790] New: arguments are displayed as reference or pointer to normal type in GDB
Here is a testcase: fmain.f: = dimension a(10) call sub(a,10) fsub.f: = subroutine sub(a,n) dimension a(n) do i = 1, n a(i) = sqr(i) end do return end subroutine function sqr(m) sqr = m * m end function build a binary: # gfortran -g -o fbase fmain.f fsub.f # gdb -q ./fbase Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) b sub_ Breakpoint 1 at 0x804876b: file fsub.f, line 21. (gdb) b sqr_ Breakpoint 2 at 0x80487c1: file fsub.f, line 30. (gdb) r Starting program: /root/DE/gdb-6.4/src/gdb/testsuite/gdb.fortran/fbase Test begin. Breakpoint 1, sub_ (a=0xbff5cf30, [EMAIL PROTECTED]) at fsub.f:21 21 do i = 1, n Current language: auto; currently fortran (gdb) p a $1 = (PTR TO - ( real*4 (0:-1))) 0xbff5cf30 (gdb) p n $2 = (REF TO - ( int4 )) @0x8048918: 10 (gdb) c Continuing. Breakpoint 2, sqr_ ([EMAIL PROTECTED]) at fsub.f:30 30tmp1 = m (gdb) p m $3 = (REF TO - ( int4 )) @0xbff5cf00: 1 (gdb) In the above debugging session, argument 'a' of sub is displayed as pointer of the normal type, 'n' of sub and 'm' of sqr are displayed as reference to normal type. -- Summary: arguments are displayed as reference or pointer to normal type in GDB Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: woodzltc at sources dot redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug fortran/24546] [meta-bug] gfortran debugging problems
--- Comment #4 from woodzltc at sources dot redhat dot com 2005-11-11 09:18 --- Hi Andrew, I opened PR 24790 to track this. Wish that it is just what you thought of. But I didn't figure out how to assign that to you. So I add you the cc list. Regards - Wu Zhou -- woodzltc at sources dot redhat dot com changed: What|Removed |Added BugsThisDependsOn||24790 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #6 from jakub at gcc dot gnu dot org 2005-11-11 09:31 ---
Here complete_vars is called (via
complete_type-instantiate_class_template-finish_struct_1 call chain) before
TYPE_NEEDS_CONSTRUCTING flag is set
(mark_used-instantiate_decl-tsubst-build_cplus_array_type call chain),
so TREE_READONLY is set on the decl and later on its type becomes
TYPE_NEEDS_CONSTRUCTING.
complete_vars calls complete_type before calling cp_apply_type_quals_to_decl,
and complete_type should presumably set TYPE_NEEDS_CONSTRUCTING flag
(typeck.c:112), but in this case TYPE_NEEDS_CONSTRUCTING is still set only
on the inner array (t) and not on TYPE_MAIN_VARIANT (t).
A quick hack could be to dive recursively in cp_apply_type_quals_to_decl
into ARRAY_TYPEs, as in:
...
type_quals = ~TYPE_QUAL_CONST;
else
for (; TREE_CODE (type) == ARRAY_TYPE; type = TREE_TYPE (type))
if (TYPE_NEEDS_CONSTRUCTNG (type) || TYPE_HAS_MUTABLE_P (type))
{
type_quals = ~TYPE_QUAL_CONST;
break;
}
c_apply_type_quals_to_decl (type_quals, decl);
or in complete_type looking at both t and its main variant:
TYPE_NEEDS_CONSTRUCTING (type)
= TYPE_NEEDS_CONSTRUCTING (t) || TYPE_NEEDS_CONSTRUCTING
(TYPE_MAIN_VARIANT (t));
TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)
= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t) ||
TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TYPE_MAIN_VARIANT (t));
Note that complete_type doesn't update TYPE_NEEDS_CONSTRUCTING etc. for
main variant, just for the type that has been requested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug c/24788] getting complier error:Internal compiler error in ix86_attr_length_immediate_default
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-11 09:31 --- Note that the gcc 3.3 series is no longer in active maintainace. You may either want to contact your vendor about your problems or upgrade to at least the gcc 3.4 series. Also you should follow instructions in the bug-reporting URL provided as investigating a problem without a proper testcase is impossible. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24788
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-11 09:39 ---
Or broadcast both flags to all type variants similarly how
layout_type-finalize_type_size broadcasts type size etc.
I.e.
- TYPE_NEEDS_CONSTRUCTING (type)
-= TYPE_NEEDS_CONSTRUCTING (TYPE_MAIN_VARIANT (t));
- TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)
-= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TYPE_MAIN_VARIANT (t));
+ unsigned need_constructing = TYPE_NEEDS_CONSTRUCTING (TYPE_MAIN_VARIANT
(t));
+ unsigned nontriv_destructor = TYPE_HAS_NONTRIVIAL_DESTRUCTOR
(TYPE_MAIN_VARIANT (t));
+ for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
+ {
+ TYPE_NEEDS_CONSTRUCTING (t) = need_constructing;
+ TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t) = nontriv_destructor;
+ }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug c++/24791] New: ICE on invalid instantiation of template's static member
tracked down sample is:
$ cat xx.cc
template int I
struct A
{
int get_val() const;
static int val_;
};
template int I
int AI::get_val() const
{
return val_;
}
template int I // this is invalid: works with template
int A0::val_(0);
// must instantiate to get ICE
template class A0;
$ g++ -v
Reading specs from
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with:
/tools/snapshot/src/sapc154/toolsbox-3.5.1.4pre.20051110/buildroot/gcc/gcc-3.4.4/configure
--with-gnu-as --with-gnu-ld --enable-threads=posix
--with-as=/tools/snapshot/toolsbox-3.5.1.4pre.20051110//i686-pc-linux-gnu/bin/as
--with-ld=/tools/snapshot/toolsbox-3.5.1.4pre.20051110//i686-pc-linux-gnu/bin/ld
--with-local-prefix=/tools/snapshot/toolsbox-3.5.1.4pre.20051110/ --disable-nls
--prefix=/tools/snapshot/toolsbox-3.5.1.4pre.20051110/
Thread model: posix
gcc version 3.4.4
$ g++ -v -c xx.cc
Reading specs from
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with:
/tools/snapshot/src/sapc154/toolsbox-3.5.1.4pre.20051110/buildroot/gcc/gcc-3.4.4/configure
--with-gnu-as --with-gnu-ld --enable-threads=posix
--with-as=/tools/snapshot/toolsbox-3.5.1.4pre.20051110//i686-pc-linux-gnu/bin/as
--with-ld=/tools/snapshot/toolsbox-3.5.1.4pre.20051110//i686-pc-linux-gnu/bin/ld
--with-local-prefix=/tools/snapshot/toolsbox-3.5.1.4pre.20051110/ --disable-nls
--prefix=/tools/snapshot/toolsbox-3.5.1.4pre.20051110/
Thread model: posix
gcc version 3.4.4
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-quiet -v -iprefix
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/
-D_GNU_SOURCE xx.cc -quiet -dumpbase xx.cc -mtune=pentiumpro -auxbase xx
-version -o /tmp/ccuQDWYE.s
ignoring nonexistent directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4
ignoring duplicate directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/i686-pc-linux-gnu
ignoring duplicate directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/backward
ignoring duplicate directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//lib/gcc/i686-pc-linux-gnu/3.4.4/include
ignoring nonexistent directory
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/i686-pc-linux-gnu
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/backward
/tools/snapshot/toolsbox-3.5.1.4pre.20051110/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/include
/tools/snapshot/toolsbox-3.5.1.4pre.20051110//include
/usr/include
End of search list.
GNU C++ version 3.4.4 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
xx.cc:18: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on invalid instantiation of template's static member
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot haubenwallner at salomon dot at
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug ada/22333] [4.1 Regression] ACATS FAIL c34007p c34007r c45282b spurious discriminant CONSTRAINT_ERROR
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-11-11 10:32 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-08 18:42:55 |2005-11-11 10:32:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22333
[Bug java/24792] New: Inner interface's are not know inside package's
#!/bin/sh
mkdir test_pack
cat test_pack/DisplayRenderer.java EOF
package test_pack;
import test_pack.StyledText.*;
class DisplayRenderer
{
StyledText text;
DisplayRenderer (StyledText parent)
{
text = parent;
}
protected void test ()
{
LineCache lineCache;
}
}
EOF
cat test_pack/StyledText.java EOF
package test_pack;
public class StyledText
{
LineCache lineCache;
public StyledText (int a)
{
}
public LineCache getCache ()
{
return lineCache;
}
interface LineCache
{
public void calculate (int startLine, int lineCount);
}
}
EOF
gcj -C test_pack/*.java
gives
test_pack/DisplayRenderer.java:12: error: Type 'LineCache' not found in the
declaration of the local variable 'lineCache'.
LineCache lineCache;
^
1 error
Verified on HEAD. For more details, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172853
--
Summary: Inner interface's are not know inside package's
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: aph at redhat dot com
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24792
[Bug java/24792] Inner interface's are not know inside package's
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-11 12:12 --- Oops. *** This bug has been marked as a duplicate of 8544 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24792
[Bug java/8544] Inner interface's are not know inside package's
--- Comment #5 from jakub at gcc dot gnu dot org 2005-11-11 12:12 --- *** Bug 24792 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8544
[Bug tree-optimization/24793] New: ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
The tree check after IVOPTs is reporting /opt/gcc/4.1-devel/bin/gfortran -S -o /dev/null -O1 -m32 grd2c.fppized.min.f grd2c.fppized.min.f: In function jkbcdf: grd2c.fppized.min.f:34: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug tree-optimization/24793] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-11 12:15 --- Created an attachment (id=10213) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10213action=view) reduced testcase Testcase is from SPEC 2006 416.gamess -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug fortran/18883] ICE in gfc_finish_var_decl
--- Comment #9 from eedelman at gcc dot gnu dot org 2005-11-11 12:18 --- Fixed on 4.1. Not yet fixed on 4.0, because it depends on PR 15326 which hasn't been fixed for 4.0. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15326 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #8 from aj at gcc dot gnu dot org 2005-11-11 12:26 --- I got the same ICE with one of the SPEC2006 candidate benchmarks on x86_64-linux-gnu. -- aj at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||15502 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/23815] Add -byteswapio flag
--- Comment #15 from rrr6399 at futuretek dot com 2005-11-11 13:26 --- I think the approach of having multiple ways of changing the behavior is a good one. Many Unix programs do this kind of thing to allow the user to choose the best way to accomplish the goal. I've found each approach useful in the past. The environment variable approach also allows the same executable to be used for different scenarios. The only negative I see is if the executable was compiled by a different compiler (ifort, pgf95, etc.). A user might expect that the behavior will change with an environment variable setting and then wonder why it didn't. Perhaps the same environment variable names used by ifort could be used by gfortran to limit this issue a bit? (In reply to comment #14) Thomas, I'm not in favor of environmental variables, which I think would also be Paul Brook's position. It's too easy to have the variables set or unset at the wrong time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #22 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-11-11 13:33 --- Subject: Re: [4.1 regression] elemental.f90 testsuite failure (-fweb) Is this a 4.0 regression too? yes, the C testcase reproduces for me in 4.0 in the same way, except that -fweb must be added to the flags. The same patch applies and fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #23 from rakdver at gcc dot gnu dot org 2005-11-11 13:38 --- Subject: Bug 22509 Author: rakdver Date: Fri Nov 11 13:38:07 2005 New Revision: 106783 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106783 Log: PR rtl-optimization/22509 * local-alloc.c (memref_used_between_p): Check whether a function call could not reference the memref. Modified: trunk/gcc/ChangeLog trunk/gcc/local-alloc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #10 from amylaar at gcc dot gnu dot org 2005-11-11 13:39 --- (In reply to comment #1) Most (if not all) of these issues are usually a pass depending on addresses being the same. I think David E. has a bug filed about one of these issues already. I've tried to search bugzilla for edelsohn and [EMAIL PROTECTED], but came up empty each time. The patch I posted appears to fix the different-code issues, but there is still an issue with random debug information layout. I would like to spin off the random debug info issue into a separate PR - an old one if you can find a matching one, otherwise we'll have to open a new one. Whith PR24760 narrowed to the random code issue from unrolling, we can progress it as having a tested patch to fix it, i.e. set the patch keyword and the patch URL field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug libfortran/24794] New: problem with namelist input of character array
Here is a test program and an input file demostrating the problem: [EMAIL PROTECTED] ~/namelist $ cat namelist.f90 program bla implicit none integer, parameter :: maxop=15, iunit=7 character*8 namea(maxop), nameb(maxop) integer i NAMELIST/CCSOPR/ NAMEA,NAMEB OPEN (iunit, file=input.nml, status='OLD') READ (iunit, CCSOPR) CLOSE (iunit) do i = 1, maxop write (*,*) NAMEA (,i,) = , NAMEA(i) end do do i = 1, maxop write (*,*) NAMEB (,i,) = , NAMEB(i) end do end program bla [EMAIL PROTECTED] ~/namelist $ cat input.nml CCSOPR NAMEA='SPI01H','SPI02O','SPI03H','SPI04O','SPI05H','SPI06H', 'SPI07O','SPI08H','SPI09H', NAMEB='SPI01H','SPI03H','SPI05H','SPI06H','SPI08H','SPI09H', END [EMAIL PROTECTED] ~/namelist $ gfortran namelist.f90 [EMAIL PROTECTED] ~/namelist $ ./a.out NAMEA ( 1 ) = SPI01H NAMEA ( 2 ) = SPI02O NAMEA ( 3 ) = SPI03H NAMEA ( 4 ) = SPI04O NAMEA ( 5 ) = SPI05H NAMEA ( 6 ) = SPI06H NAMEA ( 7 ) = SPI07O NAMEA ( 8 ) = SPI08H NAMEA ( 9 ) = SPI09H NAMEA ( 10 ) = NAMEB='S NAMEA ( 11 ) = SPI03H NAMEA ( 12 ) = SPI05H NAMEA ( 13 ) = SPI06H NAMEA ( 14 ) = SPI08H NAMEA ( 15 ) = SPI09H NAMEB ( 1 ) = 8\u\uii NAMEB ( 2 ) = \u\u\u NAMEB ( 3 ) = 8\u\u NAMEB ( 4 ) = \u\u\u NAMEB ( 5 ) = n\u\u0677\uJ\u0677 NAMEB ( 6 ) = \u\u\u0637 NAMEB ( 7 ) = ` NAMEB ( 8 ) = wP\u NAMEB ( 9 ) = \u/\u\u NAMEB ( 10 ) = \ux^\u\u NAMEB ( 11 ) = \u6\u\u\u\u NAMEB ( 12 ) = \u\u8 NAMEB ( 13 ) = \u\u NAMEB ( 14 ) = Ht\u\u NAMEB ( 15 ) = $\u -- Summary: problem with namelist input of character array Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chjacob at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-11 14:17 --- Still thinking about if (FE_ALL_EXCEPT != 0) fedisableexcept (FE_ALL_EXCEPT); I'm not quite sure gcc would discard the reference. Did you test it, and does it fix the warning issue? If you didn't do it already, could you test it? I'm a bit reluctant to include that kind of workaround without being sure it actually works. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug c++/24795] New: [4.1 Regression] Error in dependent name-lookup
Consider the following testcase, where the call to foo(B) should be resolved
at template instantiaton time of the function template g.
struct A {};
struct B {};
void foo(A);
template class T
void g(T t)
{
foo(t);
}
void foo(B);
void bar(B b)
{
g(b);
}
This works correctly. Now add some namespace blurb (which shouldn't really
change anything here) and get
namespace X {
struct A {};
struct B {};
}
void foo(X::A);
template class T
void g(T t)
{
foo(t);
}
void foo(X::B);
void bar(X::B b)
{
g(b);
}
where 4.1 now rejects this with
t2.C: In function void g(T) [with T = X::B]:
t2.C:18: instantiated from here
t2.C:11: error: invalid initialization of reference of type X::A from
expression of type X::B
t2.C:6: error: in passing argument 1 of void foo(X::A)
even more funny, adding an unrelated overload of foo:
namespace X {
struct A {};
struct B {};
struct C {};
}
void foo(X::A);
void foo(X::C);
template class T
void g(T t)
{
foo(t);
}
void foo(X::B);
void bar(X::B b)
{
g(b);
}
we reject it with
t3.C: In function void g(T) [with T = X::B]:
t3.C:20: instantiated from here
t3.C:13: error: no matching function for call to foo(X::B)
t3.C:7: note: candidates are: void foo(X::A)
t3.C:8: note: void foo(X::C)
EDG rejects the latter two with a consistent error message (in -strict_ansi
mode):
t3.C(13): error: no instance of overloaded function foo matches the argument
list
argument types are: (X::B)
foo(t);
^
detected during instantiation of void g(T ) [with T=X::B]
compilation aborted for t3.C (code 2)
g++ accepts even the following, which may hint at the reason for the
inconsistent error messages?
namespace X {
struct B {};
}
template class T
void g(T t)
{
foo(t);
}
void foo(X::B);
void bar(X::B b)
{
g(b);
}
I'm really unsure who's at fault here and if this is rejects-valid or
rejects-invalid. Digging in the standard now, but maybe someone can
point me at the relevant section.
--
Summary: [4.1 Regression] Error in dependent name-lookup
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug libfortran/24796] New: end-of-record error when writing
I found a problem with writing an unformatted file after reading from it and encountering an end-of-file during this reading. In that case it is not possible to write to the file anymore. I do not know what the standard says about this, but ifort accepts this. [EMAIL PROTECTED]:~/chemie/sources/gfortran-bugs/write cat write.f90 program bla implicit none integer, parameter :: iunit=30 character(len=8) :: b OPEN(IUNIT,FILE=BLA,STATUS='NEW',FORM='UNFORMATTED') read (IUNIT, ERR=10, END=10) B 10 continue write (iunit) bla CLOSE(IUNIT) end program bla [EMAIL PROTECTED]:~/write gfortran-4.0.2 write.f90 [EMAIL PROTECTED]:~/write ./a.out At line 12 of file write.f90 Fortran runtime error: End of record -- Summary: end-of-record error when writing Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chjacob at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24796
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-11 15:06 ---
It looks like we are looking up the name 'foo' from bar in X only (because
X::B is a qualified type and so special name-lookup rules apply), but search
the scope of bar (or g) only from the context of g. So the following compiles:
namespace X {
struct A {};
struct B {};
}
void foo(X::A);
template class T
void g(T t)
{
foo(t);
}
namespace X {
void foo(X::B);
}
void bar(X::B b)
{
g(b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug c++/24786] Missing warning on questionable use of parameter to initialize static
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 15:11 --- Warning on blah2 means moving this warning to the middle-end and down to the end of the optimization passes, maybe way to hard and then you get inconstaint warnings at different optimization levels. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
[Bug target/24788] getting complier error:Internal compiler error in ix86_attr_length_immediate_default
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 15:14 --- We need the preprocessed source code to do anything further. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24788
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #9 from jason at gcc dot gnu dot org 2005-11-11 15:19 ---
Further reduced:
struct A
{
~A();
};
bool h(int, const A);
int f();
int i;
void g()
{
i h (({ static int l = f(); l; }),
A());
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug libgomp/24797] New: Segfault in libgomp.c/nested-1.c
Hello! Testcase libgomp.c/netsted-1.c currently segfaults when run on i686-pc-linux.gnu (pentium4) wiht non-TLS libc (Redhat 8.0): (gdb) run [Thread debugging using libthread_db enabled] [New Thread 8192 (LWP 700)] [New Thread 16385 (LWP 702)] [New Thread 8194 (LWP 703)] [New Thread 16387 (LWP 704)] [New Thread 24580 (LWP 705)] [New Thread 32773 (LWP 706)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32773 (LWP 706)] 0x42073fe0 in _int_free () from /lib/i686/libc.so.6 (gdb) Backtrace: #6 0x420da1ca in thread_start () from libc.so.6 #5 0x4005fa45 in pthread_start_thread_event () from libpthread.so.0 #4 0x4005f94d in pthread_start_thread () from libpthread.so.0 #3 0x4005e65a in __pthread_do_exit () from libpthread.so.0 #2 0x4006233c in __pthread_destroy_specifics () from libpthread.so.0 #1 0x42074a2c in free () from libc.so.6 #0 0x42073fe0 in _int_free () from libc.so.6 -- Summary: Segfault in libgomp.c/nested-1.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24797
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 15:22 --- Confirmed, DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the normal type. This might also fix the implicate bug too (I forgot the number). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 15:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-11 15:35 --- The regression has been fixed so closing. -- 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=22509
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-11 15:37 --- (In reply to comment #10) (In reply to comment #1) Most (if not all) of these issues are usually a pass depending on addresses being the same. I think David E. has a bug filed about one of these issues already. I've tried to search bugzilla for edelsohn and [EMAIL PROTECTED], but came up empty each time. [EMAIL PROTECTED], PR 4520. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug java/24798] New: classmap.db should reside in /var/lib/gcj/
From [EMAIL PROTECTED]: While we're changing things here I'd like to propose that the global database be moved from /usr/lib/gcj-x.y.z/classmap.db to somewhere like /var/lib/gcj/classmap.db. Unlike the per-package files the global database is machine-specific, so putting it in /var makes us more LSB-compliant. One practical advantage of this is that it would allow our rpms to be used on systems with readonly /usr partitions. -- Summary: classmap.db should reside in /var/lib/gcj/ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-11 15:44 --- From 14.6.2/1 one could argue that foo is a dependent name and thus is looked up in the context of the point of instantiation, bar, which should find foo(X::B). But 14.6.4/1 contradicts this in telling we search the visible decls from the point of the template definition and only those from namespaces associated with the types of the function arguments from the instantiation context and the definition context. Which would make the last, working, example a accepts-invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-11 15:44 --- There are a couple of DR reports about this issue. Basicially what you are doing is invalid (IIRC). The error message which EDG is less helpful than the error message GCC gives because it does not list the overloaded set while GCC does. That is the only difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-11 15:47 --- (In reply to comment #2) Which would make the last, working, example a accepts-invalid. You missed Argument dependent namelookup rules (Koenig) which is 3.4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-11 15:49 --- Anyways the revelevent bug reports about why the second and thrid examples are invalid code are PR 5660 and PR 2922. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-11 15:57 --- This is invalid. The last example has argument-dependent lookup working which is still required to run even after finding an overloaded set. PR 2922 explains all this correctly (and so does the change log for the patch): * semantics.c (perform_koenig_lookup): For dependent calls, just return the set of functions we've found so far. Later, it will be augmented by those found through argument-dependent lookup. * name-lookup.c (lookup_arg_dependent): Implement DR 164 by removing the optimization that skips namespaces where the functions were originally found. -- 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=24795
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #5 from amacleod at redhat dot com 2005-11-11 16:09 --- Created an attachment (id=10214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10214action=view) patch for the problem In an attempt to prevent an infinite loop when verifying the immediate use links, an arbitrary count limit was checked which is higher than one would expect to see. Unfortunately, the limit was set too low. the original value of 30,000 uses was exceeded by this test case (It peaked at about 32,000+). The new limit should never be reached (50,000,000) If there are that many uses of a single ssa_name, I doubt compilation would ever finish for other reasons. I will run this through bootstrap/etc before checking it in, but it should be completely harmless. -- amacleod at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amacleod at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug libstdc++/24799] New: std::tr1::hash missing inheritance
The function object std::tr1::hash is required to inherit from std::unary_function, but the current implementation doesn't do so. It's member typedefs result_type and argument_type are therefore not present. Regards, John Maddock. -- Summary: std::tr1::hash missing inheritance Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at johnmaddock dot co dot uk GCC build triplet: linux.x86 GCC host triplet: linux.x86 GCC target triplet: linux.x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24799
[Bug libstdc++/24799] std::tr1::hash missing inheritance
--- Comment #1 from pcarlini at suse dot de 2005-11-11 16:16 --- Confirmed, thanks a lot! -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 16:16:29 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24799
[Bug libstdc++/24800] New: std::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
The title say it all really, the function object returned from mem_fn is an unspecified type that: 3.5: 2 The simple call wrapper shall be derived from std::unary_functioncv T*, Ret when pm is a pointer to member function with cv-qualifier cv and taking no arguments, where Ret is pms return type. 3 The simple call wrapper shall be derived from std::binary_functioncv T*, T1, Ret when pm is a pointer to member function with cv-qualifier cv and taking one argument of type T1, where Ret is pms return type. However my tests indicate that this inheritance is not taking place, and in any case the nested members result_type and argument_type are not present in the function object returned. Regards, John Maddock. -- Summary: std::mem_fn returns a function object that does not inherit from std::unary_function/binary_function Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at johnmaddock dot co dot uk GCC build triplet: linux.x86 GCC host triplet: linux.x86 GCC target triplet: linux.x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-11 16:23 ---
by 14.6.2/1 I would expect search from both instantiation and definition.
by 14.6.4/1 I would expect (as is the case for 4.1) search from the
instantiation
point to be restricted to namespace X.
I do not see how Koenig lookup can make it /fail/, but only work (and that it
doesn't).
We're still speaking about
namespace X {
struct A {};
struct B {};
}
void foo(X::A);
template class T
void g(T t)
{
foo(t);
}
void foo(X::B);
void bar(X::B b)
{
g(b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug debug/24801] New: -d option changes debug information
When compiling some files, the -da option or - AFAICT - any of its constituent options changes the generated debug information. -- Summary: -d option changes debug information Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24801
[Bug c++/24795] [4.1 Regression] Error in dependent name-lookup
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-11 16:25 --- Please someone else comment on this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug debug/24801] -d option changes debug information
--- Comment #1 from amylaar at gcc dot gnu dot org 2005-11-11 16:30 --- Created an attachment (id=10215) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10215action=view) test case For sh-elf, ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-0 ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-01 ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-02 all produce the same result (with address space randomization active), which is differs in debug info from what you get with any of: ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-1 -da ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-11 -da ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-12 -da Likewise, the debug info for ../../i686/gcc/cc1 -fpreprocessed -g -O2 l0.c -o l0.s-i0 differs from the one for: ../../i686/gcc/cc1 -fpreprocessed -g -O2 l0.c -o l0.s-i1 -da -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24801
[Bug libfortran/24794] problem with namelist input of character array
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-11 16:32 --- Confirmed in 4.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 16:32:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
[Bug libstdc++/24803] New: reference_wrapper and pointers to member functions
reference_wrapper doesn't seem to be functioning correctly with pointers to
member functions. I'm attaching my test case below. Note that the actual
wording of the TR is somewhat garbled in this case: but it's covered by
TR.DR.10.41.
Regards, John Maddock.
The test case:
#include tr1/functional
#include boost/static_assert.hpp
#include boost/type_traits/is_convertible.hpp
#include boost/type_traits/is_same.hpp
#include boost/type_traits/is_base_and_derived.hpp
#include verify_return.hpp
struct test_type
{
int member();
int cmember()const;
int member2(char);
int cmember2(char)const;
};
struct functor1 : public std::unary_functionint, double
{
double operator()(int)const;
};
struct functor2 : public std::binary_functionint, char, double
{
double operator()(int, char)const;
};
int main()
{
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::unary_functionint,
double, std::tr1::reference_wrapperdouble (int) ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::unary_functionint,
double, std::tr1::reference_wrapperdouble (*)(int) ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::unary_functiontest_type*,
int, std::tr1::reference_wrapperint (test_type::*)() ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::unary_functionconst
test_type*, int, std::tr1::reference_wrapperint (test_type::*)()const
::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::unary_functionint,
double, std::tr1::reference_wrapperfunctor1 ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::binary_functionint,
char, double, std::tr1::reference_wrapperdouble (int, char) ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::binary_functionint,
char, double, std::tr1::reference_wrapperdouble (*)(int, char) ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::binary_functiontest_type*,
char, int, std::tr1::reference_wrapperint (test_type::*)(char) ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::binary_functionconst
test_type*, char, int, std::tr1::reference_wrapperint
(test_type::*)(char)const ::value));
BOOST_STATIC_ASSERT((::boost::is_base_and_derivedstd::binary_functionint,
char, double, std::tr1::reference_wrapperfunctor2 ::value));
// now check operator():
std::tr1::reference_wrapperdouble (int)* pr1;
verify_return_type((*pr1)(0), double());
std::tr1::reference_wrapperdouble (*)(int)* pr2;
verify_return_type((*pr2)(0), double());
std::tr1::reference_wrapperint (test_type::*)()* pr3;
verify_return_type((*pr3)(0), int());
std::tr1::reference_wrapperint (test_type::*)()const* pr4;
verify_return_type((*pr4)(0), int());
std::tr1::reference_wrapperfunctor1* pr5;
verify_return_type((*pr5)(0), double());
std::tr1::reference_wrapperdouble (int, char)* pr1b;
verify_return_type((*pr1b)(0,0), double());
std::tr1::reference_wrapperdouble (*)(int, char)* pr2b;
verify_return_type((*pr2b)(0,0), double());
std::tr1::reference_wrapperint (test_type::*)(char)* pr3b;
verify_return_type((*pr3b)(0,0), int());
std::tr1::reference_wrapperint (test_type::*)()const* pr4b;
verify_return_type((*pr4b)(0,0), int());
std::tr1::reference_wrapperfunctor1* pr5b;
verify_return_type((*pr5b)(0,0), double());
}
The errors occur on invocation of the function objects:
gcc-C++-action
../../../bin/boost/libs/tr1/test/test_reference_wrapper_tricky.test/gcc-4.0.2/debug/test_reference_wrapper_tricky.o
/home/john/boost/libs/tr1/test/test_reference_wrapper_tricky.cpp: In function
`int main()':
/home/john/boost/libs/tr1/test/test_reference_wrapper_tricky.cpp:56: error: no
match for call to `(std::tr1::reference_wrapperint (test_type::*)()) (int)'
/usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/ref_wrap_iterate.h:42:
note: candidates are: typename std::tr1::result_oftypename
std::tr1::_Function_to_function_pointer_Tp,
std::tr1::is_function_Tp::value::type ()()::type
std::tr1::reference_wrapper_Tp::operator()() const [with _Tp = int
(test_type::*)()]
/usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/functional_iterate.h:169:
note: typename std::tr1::result_oftypename
std::tr1::reference_wrapper_Tp::_M_func_type ()(_T1)::type
std::tr1::reference_wrapper_Tp::operator()(_T1) const [with _T1 = int, _Tp =
int (test_type::*)()]
/home/john/boost/libs/tr1/test/test_reference_wrapper_tricky.cpp:58: error: no
match for call to `(std::tr1::reference_wrapperint (test_type::*)()const)
(int)'
/usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/ref_wrap_iterate.h:42:
note: candidates are: typename std::tr1::result_oftypename
std::tr1::_Function_to_function_pointer_Tp,
std::tr1::is_function_Tp::value::type ()()::type
std::tr1::reference_wrapper_Tp::operator()() const [with _Tp = int
(test_type::*)()const]
[Bug libfortran/24796] end-of-record error when writing
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-11 16:38 --- This works fine in 4.1 with my upcoming patches. Hex dump of file looks good. May be a duplicate of pr24700. Could someone else try this with an unpatched tree so I don't have to mess with my very delicateky balanced tree here. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24796
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #12 from amylaar at gcc dot gnu dot org 2005-11-11 16:32 --- (In reply to comment #11) [EMAIL PROTECTED], PR 4520. Thanks. This PR is indeed about a different issue, so I have opened PR24801 to track the debug info issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-11 16:40 --- This was voted into WP at the October 2005 meeting. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2005-09-30 05:18:43 |2005-11-11 16:40:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug libstdc++/24800] std::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
--- Comment #1 from pcarlini at suse dot de 2005-11-11 16:44 --- Can you please attach a simple testcase? Thanks. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug libstdc++/24799] std::tr1::hash missing inheritance
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24799
[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Known to fail||4.1.0 Known to work||4.0.0 Summary|ICE: expected ssa_name, have|[4.1 Regression] ICE: |var_decl in verify_ssa, at |expected ssa_name, have |tree-ssa.c:746 |var_decl in verify_ssa, at ||tree-ssa.c:746 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 16:51 --- This is a fortran front-end bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 16:51:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-11 16:58 --- This is related to PR 23202. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23202 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|minor Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #10 from jason at gcc dot gnu dot org 2005-11-11 17:15 --- Subject: Bug 24686 Author: jason Date: Fri Nov 11 17:14:49 2005 New Revision: 106786 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106786 Log: PR c++/24686 * gimplify.c (gimplify_cleanup_point_expr): Also save and restore the cleanup list. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24804] New: Produces wrong code
Compile the following program (minimized from a larger context) with
'g++ -O3 -fno-strict-aliasing foo.cpp' (on a Linux i386 32-bit machine
with gcc 3.4.4)
foo.cpp:
===
class DummyType
{
public:
inline DummyType() { }
inline ~DummyType() { }
};
class Foo
{
public:
Foo() : X0(0), X4(0) { }
int X0, X1, X2, X3, X4;
};
int main()
{
{
Foo f;
DummyType();
}
Foo f2;
while (1) {
if (f2.X4 != 0) {
f2.X4 = 0;
} else {
break;
}
}
return 0;
}
=
It will hang if you execute it.
It does not hang if you do _one_ of the following things:
- Compile with -O1 (instead of -O3)
- Remove compiler flag -fno-strict-aliasing
- Replace all occurrences of 'f2.X4' with 'f2.X3'
- Remove the statement 'DummyType();'
- Remove the statement 'Foo f;'
--
Summary: Produces wrong code
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abottema at mathworks dot com
GCC build triplet: ix86-linux
GCC host triplet: ix86-linux
GCC target triplet: ix86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #11 from jason at gcc dot gnu dot org 2005-11-11 17:15 --- Subject: Bug 24686 Author: jason Date: Fri Nov 11 17:15:48 2005 New Revision: 106787 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106787 Log: PR c++/24686 * gimplify.c (gimplify_cleanup_point_expr): Also save and restore the cleanup list. Added: trunk/gcc/testsuite/g++.dg/ext/stmtexpr7.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug libstdc++/24805] New: No non-member swap for shared_ptr
Title say it all really, there appears to be no non-member swap for shared_ptr. TR.2.2.1 has: // [2.2.3.8] shared_ptr specialized algorithms templateclass T void swap(shared_ptrT a, shared_ptrT b); But code like: #include tr1/memory using std::tr1::swap; doesn't compile: /home/john/boost/libs/tr1/test/test_shared_ptr.cpp: In function `int main()': /home/john/boost/libs/tr1/test/test_shared_ptr.cpp:94: error: `swap' is not a member of `std::tr1' /home/john/boost/libs/tr1/test/test_shared_ptr.cpp:95: error: `swap' was not declared in this scope Regards, John Maddock. -- Summary: No non-member swap for shared_ptr Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at johnmaddock dot co dot uk GCC build triplet: linux.x86 GCC host triplet: linux.x86 GCC target triplet: linux.x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24805
[Bug libfortran/24796] end-of-record error when writing
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-11 17:27 --- Jerry, here's gfortran 4.1 from last night. kargl[205] gfc41 -static -o z b.f90 kargl[206] ./z At line 11 of file b.f90 Fortran runtime error: End of record kargl[207] -- 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=24796
[Bug libstdc++/24805] No non-member swap for shared_ptr
--- Comment #1 from pcarlini at suse dot de 2005-11-11 17:30 --- Confirmed, thanks! -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:30:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24805
[Bug c++/24804] Produces wrong code
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 17:41 --- Can you give the output of gcc -v? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||3.4.0 4.1.0 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug c++/24686] [4.0 Regression] ICE when building a variation of NMSTL
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-11 17:42 --- Fixed at least on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.0 Known to work||3.4.0 4.1.0 Summary|[4.0/4.1 Regression] ICE|[4.0 Regression] ICE when |when building a variation of|building a variation of |NMSTL |NMSTL http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug target/24445] [4.1 Regression] unable to find a register to spill in class 'R0_REGS
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-11 17:43 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
[Bug c++/24795] Error in dependent name-lookup
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-11 17:45 --- (In reply to comment #7) by 14.6.2/1 I would expect search from both instantiation and definition. by 14.6.4/1 I would expect (as is the case for 4.1) search from the instantiation point to be restricted to namespace X. I do not see how Koenig lookup can make it /fail/, but only work (and that it doesn't). Koenig lookup does not apply here as foo is not in the namespace X. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1 Regression] Error in |Error in dependent name- |dependent name-lookup |lookup http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
[Bug middle-end/24804] [3.4 Regression] Produces wrong code
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 17:48 --- Confirmed, only a 3.4 regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.4.5 Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:48:26 date|| Summary|Produces wrong code |[3.4 Regression] Produces ||wrong code Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug c++/24745] unpleasant warning for if (NULL)
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-11 17:49 --- Confirmed, not a regression. -- 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 |2005-11-11 17:49:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24745
[Bug target/24764] TARGET_MEMORY_MISMATCH_STALL is never used
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 17:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:51:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24764
[Bug target/24765] TARGET_USE_BIT_TEST is never used
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 17:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:51:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24765
[Bug target/24766] Unused TARGET_DECOMPOSE_LEA
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-11 17:52 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:52:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24766
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-11 17:52 --- Confirmed. -- 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 |2005-11-11 17:52:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug debug/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Comment #13 from halcy0n at gentoo dot org 2005-11-11 17:52 --- You should be able to reproduce this by setting BOOT_CFLAGS=-O2. Eliminating that allows me to successfully compile gcc-4.1 on x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug middle-end/24434] [4.0/4.1 Regression] get_varargs_alias_set returns 0 always
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 17:55 --- Confirmed. -- 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 |2005-11-11 17:55:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24434
[Bug libfortran/24787] [libfortran] SCAN is broken
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 17:57 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00803.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:57:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24787
[Bug c/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #26 from dje at gcc dot gnu dot org 2005-11-11 17:59 --- Subject: Bug 24644 Author: dje Date: Fri Nov 11 17:59:54 2005 New Revision: 106791 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106791 Log: PR 24644 * common.opt (Wvolatile-register-var): New. * varasm.c (make_decl_rtl): Only emit warning when option specified. Clarify warning message. * doc/invoke.texi (Wvolatile-register-var): Document new option. * doc/md.texi (copysign): Document standard named pattern. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/doc/md.texi trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug fortran/24806] New: accepts invalid DO construct code
Mainline gfortran accepts following invalid code. $ cat do_test.f90 program test_do j = 0 loop: do 100 i = 1, 2 j = j + 1 100 continue end program test_do $ gfortran do_test.f90 $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051110 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051110/bin/as --with-ld=/opt/gcc-nightly/trunk-20051110/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051110 Thread model: posix gcc version 4.1.0 20051110 (experimental) -- Summary: accepts invalid DO construct code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powepc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24806
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-11-11 18:01 --- Created an attachment (id=10216) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10216action=view) Testcase that fails at -O on every branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-11-11 18:03 --- That's a pretty serious issue (the testcase comes from Perl). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Known to fail|3.4.3 4.0.0 |3.4.3 4.0.0 4.1.0 Last reconfirmed|2005-02-20 00:03:52 |2005-11-11 18:03:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug fortran/20839] do-loop with do-construct-name needs needs end do
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-18 06:02:13 |2005-11-11 17:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20839
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-11-11 18:06 --- I think basereg_operand should not look inside SUBREGs. Here's an excerpt from PA's deprecated basereg_operand: return (GET_CODE (op) == REG REG_POINTER (op) register_operand (op, mode)); I'm going to attach the proposed fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-11-11 18:06 --- Created an attachment (id=10217) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10217action=view) Proposed fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug c++/24786] Missing warning on questionable use of parameter to initialize static
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-11 17:59 ---
Actually we should be able to warn about this as = { x }; is only ran
once, the first time the blah2 is called.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2005-11-11 17:59:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
[Bug c++/24686] [4.0 Regression] ICE when building a variation of NMSTL
--- Comment #13 from jason at gcc dot gnu dot org 2005-11-11 18:17 --- Subject: Bug 24686 Author: jason Date: Fri Nov 11 18:17:25 2005 New Revision: 106794 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106794 Log: PR c++/24686 * gimplify.c (gimplify_cleanup_point_expr): Also save and restore the cleanup list. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/stmtexpr7.C - copied unchanged from r106788, trunk/gcc/testsuite/g++.dg/ext/stmtexpr7.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug fortran/24807] New: Fortran supports real*16, but not complex*32
The following piece of code shows subroutine a implicit none real*16 x complex*32 y end subroutine a that gfortran $ ~/gcc/bin/gfortran --version GNU Fortran 95 (GCC) 4.1.0 20051110 (experimental) supports the datatype real*16, but not complex*32. Since a complex*32 consists essentially of two real*16 components, either both or none should be supported. -- Summary: Fortran supports real*16, but not complex*32 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.3.0 GCC host triplet: powerpc-apple-darwin8.3.0 GCC target triplet: powerpc-apple-darwin8.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24807
[Bug tree-optimization/23311] [4.0 regression] GCC produces wrong code
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-11 18:22 --- No feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23311
[Bug c++/24686] [4.0 Regression] ICE when building a variation of NMSTL
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-11 18:24 --- 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=24686
[Bug libstdc++/24808] New: is_object fails to compile with incomplete types
Title says it all really, code like: #include tr1/type_traits struct foo; static const bool b = std::tr1::is_objectfoo::value; doesn't compile, when it should: although many of the type_traits have a precondition that they need not work with incomplete types, this isn't one of those traits. Oh and the error message was: /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits: In instantiation of `const bool std::tr1::__conv_helperincomplete_type, incomplete_type*::__value': /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:192: instantiated from `const bool std::tr1::__is_function_helperincomplete_type, false::__value' /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:202: instantiated from `std::tr1::is_functionincomplete_type' /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:222: instantiated from `std::tr1::is_objectincomplete_type' /home/john/boost/libs/type_traits/test/is_object_test.cpp:24: instantiated from here /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:62: error: invalid use of undefined type `struct incomplete_type' /home/john/boost/libs/type_traits/test/test.hpp:349: error: forward declaration of `struct incomplete_type' Regards, John Maddock. -- Summary: is_object fails to compile with incomplete types Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at johnmaddock dot co dot uk GCC build triplet: linux.x86 GCC host triplet: linux.x86 GCC target triplet: linux.x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24808
[Bug c++/22489] [4.0/4.1 Regression] ICE in dwarf2out_finish with using namespace in a local class and compiler built constructors
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-07-14 14:38:31 |2005-11-11 18:40:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22489
[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
--- Comment #2 from john at johnmaddock dot co dot uk 2005-11-11 18:42 --- Created an attachment (id=10218) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10218action=view) Test case (caution complicated) The attached test cases are rather complex - sorry but it's easier to give you all the bad news at once :-) They also depend on Boost, and you'll need to change the include from functional to tr1/functional to mesh with gcc's current (non-conforming?) include style. As for the original bug report: it's easy to verify by inspecting the source that _Mem_fn has no base class as required. Hope this gives you what you need. John Maddock -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug libstdc++/24809] New: is_polymorphic doesn't compile if the argument type has non-throwing destructor
Title say it all really, test case is: #include tr1/type_traits #include exception static const bool b = std::tr1::is_polymorphicstd::exception::value; which produces: /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits: In instantiation of `std::tr1::__is_polymorphic_helperstd::exception, false::__secondstd::exception': /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:328: instantiated from `const bool std::tr1::__is_polymorphic_helperstd::exception, false::__value' /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:338: instantiated from `std::tr1::is_polymorphicstd::exception' /home/john/boost/libs/type_traits/test/is_polymorphic_test.cpp:61: instantiated from here /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/tr1/type_traits:324: error: looser throw specifier for `std::tr1::__is_polymorphic_helper_Tp, anonymous ::__second_Up::~__second() [with _Up = std::exception, _Tp = std::exception, bool anonymous = false]' /usr/local/gcc/4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/exception:58: error: overriding `virtual std::exception::~exception() throw ()' Regards, John Maddock. -- Summary: is_polymorphic doesn't compile if the argument type has non-throwing destructor Product: gcc Version: 3.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at johnmaddock dot co dot uk GCC build triplet: linux.x86 GCC host triplet: linux.x86 GCC target triplet: linux.x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24809
[Bug debug/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-11 18:50 --- This is a bug still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug debug/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap without -g
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-11 18:50 --- so with -g, it works but without -g it does not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P2 |P3 Last reconfirmed|-00-00 00:00:00 |2005-11-11 18:50:50 date|| Summary|[4.1 Regression] gcc HEAD as|[4.1 Regression] gcc HEAD as |of 2005/07/05 fails to |of 2005/07/05 fails to |profiledbootstrap |profiledbootstrap without -g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
