[Bug fortran/31917] New: GFORTRAN_CONVERT_UNIT is ignored
http://gcc.gnu.org/onlinedocs/gfortran/GFORTRAN_005fCONVERT_005fUNIT.html
Result (on x86_64/Linux):
GFORTRAN_CONVERT_UNIT set to ""
default:"LITTLE_ENDIAN"
native:"LITTLE_ENDIAN"
swap:"BIG_ENDIAN"
little_endian:"LITTLE_ENDIAN"
big_endian:"BIG_ENDIAN"
GFORTRAN_CONVERT_UNIT set to "BIG_ENDIAN" ! same with "big_endian"
default:"LITTLE_ENDIAN"
native:"LITTLE_ENDIAN"
swap:"BIG_ENDIAN"
little_endian:"LITTLE_ENDIAN"
big_endian:"BIG_ENDIAN"
Test program
program conv
implicit none
character(20) :: ch
CALL GET_ENVIRONMENT_VARIABLE('GFORTRAN_CONVERT_UNIT', ch)
print '(3a)', 'GFORTRAN_CONVERT_UNIT set to "',trim(ch),'"'
open(11,form='unformatted'); inquire(11,convert=ch)
print '(3a)', 'default:"',trim(ch),'"'; close(11,status='delete')
open(12,form='unformatted',convert="native")
inquire(12,convert=ch)
print '(3a)', 'native:"',trim(ch),'"'; close(12,status='delete')
open(13,form='unformatted',convert="swap")
inquire(13,convert=ch)
print '(3a)', 'swap:"',trim(ch),'"'; close(13,status='delete')
open(14,form='unformatted',convert="little_endian")
inquire(14,convert=ch)
print '(3a)', 'little_endian:"',trim(ch),'"'; close(14,status='delete')
open(15,form='unformatted',convert="big_endian")
inquire(15,convert=ch)
print '(3a)', 'big_endian:"',trim(ch),'"'; close(15,status='delete')
end program conv
--
Summary: GFORTRAN_CONVERT_UNIT is ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug fortran/31917] GFORTRAN_CONVERT_UNIT is ignored
--- Comment #1 from dominiq at lps dot ens dot fr 2007-05-14 08:52 --- On PPC/darwin7 I get [karma] f90/bug% a.out GFORTRAN_CONVERT_UNIT set to "" default:"BIG_ENDIAN" native:"BIG_ENDIAN" swap:"LITTLE_ENDIAN" little_endian:"LITTLE_ENDIAN" big_endian:"BIG_ENDIAN" [karma] f90/bug% setenv GFORTRAN_CONVERT_UNIT LITTLE_ENDIAN [karma] f90/bug% a.out GFORTRAN_CONVERT_UNIT set to "LITTLE_ENDIAN" default:"BIG_ENDIAN" native:"BIG_ENDIAN" swap:"LITTLE_ENDIAN" little_endian:"LITTLE_ENDIAN" big_endian:"BIG_ENDIAN" However I am confused about what to expect from this test: should the default change or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #60 from rguenth at gcc dot gnu dot org 2007-05-14 09:25 --- But it doesn't have a result, does it? Given that, I wonder how moving stmts across it is prevented? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/986] g++ misses warning for & on temporary
--- Comment #20 from raf2 at msux dot cjb dot net 2007-05-14 09:30 --- We have talked about the undefined behaviour of having references to objects that have been destroyed. Can someone provide a program with that undefined behaviour that could not be considered an error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug fortran/31918] New: -fconvert only accepts native and swap, but not little_endian or big_endian
http://gcc.gnu.org/onlinedocs/gfortran/Runtime-Options.html#Runtime-Options $ gfortran -fconvert=native test.f90 $ gfortran -fconvert=swap test.f90 $ gfortran -fconvert=little_endian test.f90 f951: error: unrecognized command line option "-fconvert=little_endian" $ gfortran -fconvert=big_endian test.f90 f951: error: unrecognized command line option "-fconvert=big_endian" Expected: big_endian and little_endian are supported as well -- Summary: -fconvert only accepts native and swap, but not little_endian or big_endian Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31918
[Bug fortran/31917] GFORTRAN_CONVERT_UNIT is ignored
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-14 09:38 --- > GFORTRAN_CONVERT_UNIT set to "" > default:"BIG_ENDIAN" > GFORTRAN_CONVERT_UNIT set to "LITTLE_ENDIAN" > default:"BIG_ENDIAN" > However I am confused about what to expect from this test: > should the default change or not? I would expect that the default changes depending on the environment variable. But according to the documentation all should change: "Note that the values specified via the GFORTRAN_CONVERT_UNIT environment variable will override the CONVERT specifier in the open statement. This is to give control over data formats to users who do not have the source code of their program available." Documentation "bug": Such a statement is missing for GFORTRAN_CONVERT_UNIT section; it is only present in the CONVERT specifier section: http://gcc.gnu.org/onlinedocs/gfortran/CONVERT-specifier.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #14 from P dot Schaffnit at access dot rwth-aachen dot de 2007-05-14 10:06 --- Hi! Sorry about the noise, I'm wondering: the trick of using a tiny C routine: kill ( (pid_t)0, SIGILL ); is there any obvious reason for that? Thanks! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug c++/14688] Mis-matched calling convention on virtual functions accepted without error
--- Comment #4 from justin dot forest at gmail dot com 2007-05-14 10:57 --- $ g++ --version i686-apple-darwin8-g++- 4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ -o test test.cc && ./test two::test(0xb7d8, 0xb7d8) two::test(0xb7d8, 0x1b94) Still looks like a valid issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688
[Bug c/31916] inconsistency between gcc and g++ with regards to pthreads
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-14 12:00 --- And this is not a GCC bug, define _GNU_SOURCE in the C case if you want the extra functionality from glibc. g++ defines it because libstdc++ uses some of it in its headers. -- 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=31916
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
On 14 May 2007 08:25:27 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: --- Comment #60 from rguenth at gcc dot gnu dot org 2007-05-14 09:25 --- But it doesn't have a result, does it? Given that, I wonder how moving stmts across it is prevented? Okay, so then it needs an LHS that defines a new SSA name, otherwise, we'll end up with dead ones everywhere, and they will keep other dead code alive.
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #61 from dberlin at gcc dot gnu dot org 2007-05-14 12:44 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 14 May 2007 08:25:27 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #60 from rguenth at gcc dot gnu dot org 2007-05-14 09:25 > --- > But it doesn't have a result, does it? Given that, I wonder how moving stmts > across it is prevented? Okay, so then it needs an LHS that defines a new SSA name, otherwise, we'll end up with dead ones everywhere, and they will keep other dead code alive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM
--- Comment #3 from marcus at better dot se 2007-05-14 15:24 --- Subject: Re: [JNI] -X options not recognised by JNI_CreateJavaVM > Could you try this patch? I'm trying, but my brand new Thinkpad insists on rebooting every time I build gcc. Will have to investigate... Marcus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31700
[Bug fortran/31919] New: ICE in fold_binary in fold-const.c
On amd64 debian gfortran fails (both trunk and recent 4.2 from GFortran wiki): module materials implicit none integer,parameter :: dr = kind(1.0d0) private type md_field real(dr),dimension(1:3,1:99) :: realspeed real(dr),dimension(1:99) :: mass,kinenergy end type md_field contains function getTemperature(x,selector) result(temp) type(md_field),intent(in) :: x; integer,dimension(:),intent(in),optional :: selector; real(kind=dr) :: temp; ! realspeed has wrong dimensions print *,min(x % kinenergy,x % realspeed) end function getTemperature end module materials Output is: $ gfortran-trunk matbug.F90 matbug.F90: In function ‘gettemperature’: matbug.F90:12: internal compiler error: in fold_binary, at fold-const.c:8923 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. It's not valid I guess, but gfortran should not fail. -- Summary: ICE in fold_binary in fold-const.c Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keinstein_junior at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31919
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #62 from rguenth at gcc dot gnu dot org 2007-05-14 16:20
---
We ICE with
template
class Vector
{
public:
Vector()
{
for (int i = 0; i < D; ++i)
new (&x_m[i]) T2();
}
T2& operator[](int i) { return *reinterpret_cast(&x_m[i]); }
private:
T x_m[D];
};
void foo(Vector *m)
{
Vector v;
v[0] = 1;
v[1] = 2;
v[2] = 3;
*m = v;
}
(adjust the storage type to be of same size for double/long):
Program received signal SIGSEGV, Segmentation fault.
0x00b11a5e in unmodifiable_var_p (var=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-flow-inline.h:1598
1598 if (TREE_CODE (var) == SSA_NAME)
#0 0x00b11a5e in unmodifiable_var_p (var=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-flow-inline.h:1598
#1 0x00b194c3 in may_alias_p (ptr=0x2b537d358210, mem_alias_set=2,
var=0x2b537d359e00, var_alias_set=3, alias_set_only=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2685
#2 0x00b17f2b in add_flow_insensitive_var_aliases (ai=0x14d7890,
pvar=0x2b537d358210, set=2, tag=0x2b537d356ba0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2190
#3 0x00b184d3 in compute_change_dynamic_type_aliasing (
vcdt=0x2b537d357a00, vai=0x14d7890)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2242
#4 0x0098a387 in pointer_set_traverse (pset=0x14e4e10,
fn=0xb17f84 , data=0x14d7890)
at /space/rguenther/src/svn/trunk/gcc/pointer-set.c:181
#5 0x00b18719 in compute_flow_insensitive_aliasing (ai=0x14d7890)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2295
#6 0x00b15b17 in compute_may_aliases ()
where in may_alias_p the ptr we passed does not have a symbol memory tag
associated. (but var is SFT.3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #63 from dberlin at gcc dot gnu dot org 2007-05-14 16:38
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 14 May 2007 15:20:14 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #62 from rguenth at gcc dot gnu dot org 2007-05-14 16:20
> ---
> We ICE with
>
> template
> class Vector
> {
> public:
>Vector()
>{
> for (int i = 0; i < D; ++i)
> new (&x_m[i]) T2();
>}
>T2& operator[](int i) { return *reinterpret_cast(&x_m[i]); }
>
> private:
>T x_m[D];
> };
>
> void foo(Vector *m)
> {
> Vector v;
> v[0] = 1;
> v[1] = 2;
> v[2] = 3;
> *m = v;
> }
>
> (adjust the storage type to be of same size for double/long):
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00b11a5e in unmodifiable_var_p (var=0x0)
> at /space/rguenther/src/svn/trunk/gcc/tree-flow-inline.h:1598
> 1598 if (TREE_CODE (var) == SSA_NAME)
>
> #0 0x00b11a5e in unmodifiable_var_p (var=0x0)
> at /space/rguenther/src/svn/trunk/gcc/tree-flow-inline.h:1598
> #1 0x00b194c3 in may_alias_p (ptr=0x2b537d358210, mem_alias_set=2,
> var=0x2b537d359e00, var_alias_set=3, alias_set_only=0 '\0')
> at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2685
> #2 0x00b17f2b in add_flow_insensitive_var_aliases (ai=0x14d7890,
> pvar=0x2b537d358210, set=2, tag=0x2b537d356ba0)
> at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2190
> #3 0x00b184d3 in compute_change_dynamic_type_aliasing (
> vcdt=0x2b537d357a00, vai=0x14d7890)
> at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2242
> #4 0x0098a387 in pointer_set_traverse (pset=0x14e4e10,
> fn=0xb17f84 , data=0x14d7890)
> at /space/rguenther/src/svn/trunk/gcc/pointer-set.c:181
> #5 0x00b18719 in compute_flow_insensitive_aliasing (ai=0x14d7890)
> at /space/rguenther/src/svn/trunk/gcc/tree-ssa-alias.c:2295
> #6 0x00b15b17 in compute_may_aliases ()
>
> where in may_alias_p the ptr we passed does not have a symbol memory tag
> associated. (but var is SFT.3)
unmodifiable_var_p is not allowed to alias anything, so we don't
create SMT's for them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31919] ICE in fold_binary in fold-const.c
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-14 16:39 --- The problem is the handling of arrays in the MIN intrinsic. The reporter probably wanted "MIN(MINVAL(x%kinenergy), MINVAL(x%realspeed))" as the dimensions of REALSPEED and KINENERGY are not conformable. $> sunf95 pr31919.f90 "pr31919.f90", Line = 10, Column = 35: ERROR: All of the actual arguments to this intrinsic call are not conformable to each other. Slightly reduced testcase: $> cat pr31919.f90 module materials type md_field real,dimension(10, 10) :: realspeed real,dimension(10) :: mass,kinenergy end type md_field contains real function getTemperature(x) type(md_field),intent(in) :: x; print *, min(x%kinenergy, x%realspeed) end function getTemperature end module materials (gdb) bt #0 integer_zerop (expr=0x0) at ../../../svn/gcc/gcc/tree.c:1295 #1 0x080b7b66 in gfc_conv_array_index_offset (se=0xbfc63db4, info=0x887d540, dim=1, i=1, ar=0x887d2bc, stride=0xb7cb9540) at ../../../svn/gcc/gcc/fortran/trans-array.c:2145 #2 0x080b7faa in gfc_trans_preloop_setup (loop=0xbfc63e3c, dim=0, flag=1, pblock=0xbfc63ec8) at ../../../svn/gcc/gcc/fortran/trans-array.c:2365 #3 0x080b82fb in gfc_start_scalarized_body (loop=0xbfc63e3c, pbody=0xbfc63f4c) at ../../../svn/gcc/gcc/fortran/trans-array.c:2406 #4 0x080dd7cf in gfc_trans_transfer (code=0x8842510) at ../../../svn/gcc/gcc/fortran/trans-io.c:1854 #5 0x080b2cf5 in gfc_trans_code (code=0x8842510) at ../../../svn/gcc/gcc/fortran/trans.c:605 #6 0x080dfeb3 in build_dt (function=0xb7cb4580, code=0x887d408) at ../../../svn/gcc/gcc/fortran/trans-io.c:1507 #7 0x080b2d17 in gfc_trans_code (code=0x887d408) at ../../../svn/gcc/gcc/fortran/trans.c:581 #8 0x080c8973 in gfc_generate_function_code (ns=0x887c600) at ../../../svn/gcc/gcc/fortran/trans-decl.c:3181 #9 0x080b1cb8 in gfc_generate_module_code (ns=0x88421b0) at ../../../svn/gcc/gcc/fortran/trans.c:693 #10 0x0808d63e in gfc_parse_file () at ../../../svn/gcc/gcc/fortran/parse.c:3259 #11 0x080ad70d in gfc_be_parse_file (set_yydebug=0) at ../../../svn/gcc/gcc/fortran/f95-lang.c:305 #12 0x082fc538 in toplev_main (argc=2, argv=0xbfc64284) at ../../../svn/gcc/gcc/toplev.c:1051 #13 0x080f063f in main (argc=Cannot access memory at address 0x1 ) at ../../../svn/gcc/gcc/main.c:35 $> gfortran-svn -v gcc version 4.3.0 20070502 (experimental) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-05-14 16:39:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31919
[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- Comment #32 from amylaar at spamcop dot net 2007-05-14 16:39 --- Subject: Re: [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>: > > safely when the target doesn't have infinities. Therefore, I would ask you to > untangle a bit this thing... Apparently, for some reason, for your target > onte > of the checks (which one? !finitef? !finite?) is not working, instead the > final > f != __builtin_huge_valf() catches it. These are excepts from arc-elf32/arc700/libstdc++-v3/include/arc-elf32/bits/c++config.h: /* Define to 1 if you have the `finitef' function. */ /* #undef _GLIBCXX_HAVE_FINITEF */ /* Define to 1 if you have the `_finitef' function. */ /* #undef _GLIBCXX_HAVE__FINITEF */ /* Define to 1 if you have the `finite' function. */ /* #undef _GLIBCXX_HAVE_FINITE */ /* Define to 1 if you have the `_finite' function. */ /* #undef _GLIBCXX_HAVE__FINITE */ /* Define to 1 if you have the `isinf' function. */ /* #undef _GLIBCXX_HAVE_ISINF */ /* Define to 1 if you have the `_isinf' function. */ /* #undef _GLIBCXX_HAVE__ISINF */ Thus, the test that should be performed in _ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be: if (fabs(__d) > numeric_limits::max()) errno = ERANGE; Disassembly of that method shows that the test has been optimized away. This is not actually surprising, because _GLIBCXX_HAVE_STRTOF has been set, and hence strtof has been used, and __d remained uninitalized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836
[Bug fortran/31919] ICE in fold_binary in fold-const.c
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-14 16:41 --- Minimal testcase: $> cat pr31919.f90 INTEGER :: a(2), b(2,2) PRINT *, MIN(a, b) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31919
[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- Comment #33 from pcarlini at suse dot de 2007-05-14 16:54 --- (In reply to comment #32) > /* Define to 1 if you have the `finitef' function. */ > /* #undef _GLIBCXX_HAVE_FINITEF */ > /* Define to 1 if you have the `_finitef' function. */ > /* #undef _GLIBCXX_HAVE__FINITEF */ > /* Define to 1 if you have the `finite' function. */ > /* #undef _GLIBCXX_HAVE_FINITE */ > /* Define to 1 if you have the `_finite' function. */ > /* #undef _GLIBCXX_HAVE__FINITE */ > /* Define to 1 if you have the `isinf' function. */ > /* #undef _GLIBCXX_HAVE_ISINF */ > /* Define to 1 if you have the `_isinf' function. */ > /* #undef _GLIBCXX_HAVE__ISINF */ Ok, all undefined, it's possible. > Thus, the test that should be performed in > _ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be: > > if (fabs(__d) > numeric_limits::max()) > errno = ERANGE; Only *if* _GLIBCXX_HAVE_STRTOF is not defined, however. > Disassembly of that method shows that the test has been > optimized away. > This is not actually surprising, because _GLIBCXX_HAVE_STRTOF > has been set, and hence strtof has been used, and > __d remained uninitalized. Ok, therefore _GLIBCXX_HAVE_STRTOF is set and no further test is needed before the final one. In this case __d isn't optimized out, simply the pre-processor selects: float __f = strtof(__s, &__sanity); instead of double __d = strtod(__s, &__sanity); float __f = static_cast(__d); Now, the strange thing is that, before these two last patches (in 4_2-branch in other terms), errno doesn't turn out to be == ERANGE for your target: strtof should have set it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836
Simplification of 64bit multiply by constant looks wrong on IA32
For the following code given in [1] GCC produces identical multiplication by
constant code [2]. I believe the fault is with the simplification of a 64bit
multiply by 0x1 (ie low word == -1 and high word == 1) where the
effect will be a multiply by 0x0.
Thanks,
Ian Rogers
[1]
test.c:
extern long long x;
long long foo() {
return x * long long)0) << 32) + -1);
}
long long foo2() {
return x * long long)1) << 32) + -1);
}
[2]
test.s:
.file "test.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
movlx, %eax
movlx+4, %edx
pushl %ebp
movl%esp, %ebp
negl%eax
popl%ebp
adcl$0, %edx
negl%edx
ret
.size foo, .-foo
.p2align 4,,15
.globl foo2
.type foo2, @function
foo2:
movlx, %eax
movlx+4, %edx
pushl %ebp
movl%esp, %ebp
negl%eax
popl%ebp
adcl$0, %edx
negl%edx
ret
.size foo2, .-foo2
.ident "GCC: (GNU) 4.1.2 20061115 (prerelease) (SUSE Linux)"
.section.note.GNU-stack,"",@progbits
--
View this message in context:
http://www.nabble.com/Simplification-of-64bit-multiply-by-constant-looks-wrong-on-IA32-tf3753278.html#a10606700
Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #64 from ian at airs dot com 2007-05-14 17:42 --- Re: comment #59: CHANGE_DYNAMIC_TYPE_EXPR does not have a result. I set it up so that it is essentially volatile, and represents an additional type aliasing at that point in the program. One of the earlier patches set it up as a cast. But it was hard to convince myself that it really did the right thing. A lot of code in the compiler strips casts for one reason or another. One would have to examine each of those places and make sure that it did not strip the cast inappropriately. Or, conversely, that it did strip the cast when it should. This would tend to introduce a bit of code in many different parts of the compiler, all to handle a very unusual case. Generating a statement with no result seemed more reliable to me. It's true that there is a downside: it may cause a placement new to be preserved inappropriately. But that seems like an unlikely case to me. I doubt that very much code does a placement new which changes types and then does not use the resulting memory. I think it's OK to misoptimize such code slightly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug debug/31920] New: Bad location information for Java local variable
Here's a snippet from the HEAD version of gdb.java/jprint.java in the GDB
testsuite:
public static void main(String[] args) {
jprint x = new jprint ();
x.dothat (44);
print (k, 33);
}
GCC's debug info reports that x is a pointer in %rax when compiled with -g -O0.
It reports that that's true throughout the function. Unfortunately it isn't
true; it's in %rax before the call to x.dothat(44) but afterwards %rax is
garbage.
--
Summary: Bad location information for Java local variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31920
[Bug debug/31920] Bad location information for Java local variable
--- Comment #1 from drow at gcc dot gnu dot org 2007-05-14 17:45 --- Created an attachment (id=13552) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13552&action=view) Test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31920
[Bug c++/986] g++ misses warning for & on temporary
--- Comment #21 from bangerth at dealii dot org 2007-05-14 17:50 ---
This is getting completely off-topic, so here's my last post:
(In reply to comment #20)
> Can someone provide a program with that undefined behaviour that could not be
> considered an error?
As long as you don't touch the undefined value, everything's ok:
-
struct X { X (int);};
struct Y {
Y ();
int do_something () { return 1; }
const X &x; // note the ampersand
};
Y::Y () : x(1) {}; // creates a temporary and stores address
int main () {
Y y;
return y.do_something();
}
--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/29928] typeid of unknown bound array
--- Comment #4 from pcarlini at suse dot de 2007-05-14 17:52 --- I have a draft... -- 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=29928
[Bug fortran/31919] ICE in fold_binary in fold-const.c
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-14 16:39:55 |2007-05-14 17:55:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31919
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #65 from ian at airs dot com 2007-05-14 18:14 --- Created an attachment (id=13553) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13553&action=view) Patch Thanks for the new test case. Here is a new patch. The change compared to the previous patch is just that we check whether the variable has a memory tag (i.e., the variable has been written) before calling add_flow_insensitive_var_aliases, rather than after. -- ian at airs dot com changed: What|Removed |Added Attachment #13551|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31918] -fconvert only accepts native and swap, but not little_endian or big_endian
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-14 18:17 --- It should be "little-endian" (with hyphen). The environment variable and the convert=... in Fortran use underscores which confused me. I rechecked the manual and it indeed says "little-endian" with hyphen -> close as invalid -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31918
[Bug fortran/31919] ICE in fold_binary in fold-const.c
--- Comment #3 from patchapp at dberlin dot org 2007-05-14 18:30 --- Subject: Bug number PR31919 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00890.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31919
[Bug fortran/31921] New: crash for FUNCTION with RESULT specifier
module mman implicit none private public mskew,nskew contains function nskew() result(y) real :: y(1) call skewm(y) end function nskew ! function mskew() real :: mskew(1) call skewm(mskew) end function mskew ! subroutine skewm(smat) real, intent(out) :: smat(1) smat = 0.0 end subroutine skewm end module mman ! program mtst use mman, only: mskew,nskew implicit none print*,"(1) calling nskew" print*,nskew() print*,"(2) calling mskew" print*,mskew() print*,"(3) done" end program mtst Compiling with mingw gfortran 20070506 with the default options gives the incorrect warning message xfunc_bug.f90: In function 'mskew': xfunc_bug.f90:13: warning: Function does not return a value and at run time the output is (1) calling nskew 0.00 (2) calling mskew -- Summary: crash for FUNCTION with RESULT specifier Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31921
[Bug fortran/31921] crash for FUNCTION with RESULT specifier
--- Comment #1 from dominiq at lps dot ens dot fr 2007-05-14 19:14 --- Works for me on powerpc-apple-darwin7 with gfortran 4.3.0 20070511 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31921
[Bug fortran/31922] New: Accessing uninitialized variable for print *, trim(blank_string)
program x implicit none character(20) :: ch ch = ' ' print '(a)', trim(ch) end program x valgrind: ==23260== Conditional jump or move depends on uninitialised value(s) ==23260==at 0x4EBD506: formatted_transfer_scalar (transfer.c:888) ==23260==by 0x4EBDFCC: formatted_transfer (transfer.c:1362) ==23260==by 0x4009CE: MAIN__ (in /dev/shm/a.out) ==23260==by 0x400A1B: main (fmain.c:22) -- Summary: Accessing uninitialized variable for print *, trim(blank_string) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31922
[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- Comment #34 from amylaar at spamcop dot net 2007-05-14 19:25 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:
> Now, the strange thing is that, before these two last patches (in 4_2-branch
> in
> other terms), errno doesn't turn out to be == ERANGE for your target: strtof
> should have set it...
It's lameness in newlib.
newlib/libc/stdlib/strtod.c defines:
float
_DEFUN (strtof, (s00, se),
_CONST char *s00 _AND
char **se)
{
double retval = _strtod_r (_REENT, s00, se);
if (isnan (retval))
return nanf (NULL);
return (float)retval;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836
[Bug target/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #17 from pluto at agmk dot net 2007-05-14 20:02 --- (In reply to comment #16) > So, i gave it the old college try, and it turns out to be much harder > than I expected because of mem-ssa and other changes that went into > 4.3 yup, looks like a nice bullet for 4.2.0 release. with such features 4.2 will be widely /dev/nulled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/31917] GFORTRAN_CONVERT_UNIT is ignored
--- Comment #3 from patchapp at dberlin dot org 2007-05-14 20:05 --- Subject: Bug number PR31917 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00900.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug fortran/31921] crash for FUNCTION with RESULT specifier
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-14 20:06 --- I believe this is a duplicate of PR 31692 which was fixed Tue May 8, which explains that it is failing in 20070506 but working in 20070511. Please reopen if there are other issues. *** This bug has been marked as a duplicate of 31692 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31921
[Bug fortran/31692] Wrong code when passing function name as result to procedures
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-14 20:06 --- *** Bug 31921 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31692
[Bug fortran/31917] GFORTRAN_CONVERT_UNIT is ignored
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-14 20:07:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug fortran/31922] Accessing uninitialized variable for print *, trim(blank_string)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-14 20:24 ---
Jerry, you are one of the libgfortran/IO experts, could you have a look?
_gfortran_transfer_character (&dt_parm.0, pstr.1, len.2);
uses uninitialized memory if len = 0 and p = NULL. This happens because
empty_string is not initialized to anything and points to a random position.
However, it is later tested for "p == NULL".
transfer_character (st_parameter_dt *dtp, void *p, int len)
{
static char *empty_string[0];
[..]
if (len == 0 && p == NULL)
p = empty_string;
dtp->u.p.transfer (dtp, BT_CHARACTER, p, len, len, 1);
And in:
formatted_transfer_scalar (st_parameter_dt *dtp, bt type, void *p, int len,
n = (p == NULL) ? 0 : ((type != BT_COMPLEX) ? 1 : 2);
Would be the following a correctly working alternative?
static char empty_string[0];
if (len == 0 && p == NULL)
p = &empty_string;
--
burnus 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=31922
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #25 from dberlin at gcc dot gnu dot org 2007-05-14 20:01 --- > which should be the most interesting parts of the diff (apart from the > extra vops that prevent the DCE). > > Danny? Any hints on what can go wrong here? > The first pass is obviously generating wrong answers, unless someone changed the subvars. It looks like it's getting confused about where to use the whole object or the first field. Is that a diff of the dump that includes -details? I'm trying to figure out if the constraints are bad, or the solving is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug fortran/31725] substring bound evaluated multiple times: wrong code for string(function():) = 'X'
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-14 20:29 --- Subject: Bug 31725 Author: fxcoudert Date: Mon May 14 19:29:33 2007 New Revision: 124720 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124720 Log: PR fortran/31725 * trans-expr.c (gfc_conv_substring): Evaluate substring bounds only once. * gfortran.dg/substr_4.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/substr_4.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug fortran/31725] [4.1/4.2 only] substring bound evaluated multiple times: wrong code for string(function():) = 'X'
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 4.2.0 4.1.2 |4.2.0 4.1.2 Known to work||4.3.0 Summary|substring bound evaluated |[4.1/4.2 only] substring |multiple times: wrong code |bound evaluated multiple |for string(function():) = |times: wrong code for |'X' |string(function():) = 'X' Target Milestone|4.3.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug fortran/30723] Freeing memory doesn't need to call a library function
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-14 20:34 --- Subject: Bug 30723 Author: fxcoudert Date: Mon May 14 19:33:57 2007 New Revision: 124721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124721 Log: PR fortran/30723 * trans.h (gfor_fndecl_internal_malloc, gfor_fndecl_internal_malloc64, gfor_fndecl_internal_free): Remove prototypes. (gfor_fndecl_os_error, gfc_call_free, gfc_call_malloc): Add prototypes. * trans.c (gfc_call_malloc, gfc_call_free): New functions. * f95-lang.c (gfc_init_builtin_functions): Add __builtin_free and __builtin_malloc builtins. * trans-decl.c (gfor_fndecl_internal_malloc, gfor_fndecl_internal_malloc64, gfor_fndecl_internal_free): Remove. (gfor_fndecl_os_error): Add. (gfc_build_builtin_function_decls): Don't create internal_malloc, internal_malloc64 and internal_free library function declaration. Create os_error library call function declaration. * trans-array.c (gfc_trans_allocate_array_storage, gfc_trans_auto_array_allocation, gfc_trans_dummy_array_bias, gfc_conv_array_parameter, gfc_duplicate_allocatable): Use gfc_call_malloc and gfc_call_free instead of building calls to internal_malloc and internal_free. * trans-expr.c (gfc_conv_string_tmp): Likewise. * trans-stmt.c (gfc_do_allocate, gfc_trans_assign_need_temp, gfc_trans_pointer_assign_need_temp, gfc_trans_forall_1, gfc_trans_where_2: Likewise. * trans-intrinsic.c (gfc_conv_intrinsic_ctime, gfc_conv_intrinsic_fdate, gfc_conv_intrinsic_ttynam, gfc_conv_intrinsic_array_transfer, gfc_conv_intrinsic_trim): Likewise. * runtime/memory.c (internal_malloc, internal_malloc64, internal_free): Remove. * runtime/error.c (os_error): Export function. * intrinsics/move_alloc.c: Include stdlib.h. (move_alloc): Call free instead of internal_free. (move_alloc_c): Wrap long lines. * libgfortran.h (os_error): Export prototype. (internal_free): Remove prototype. * gfortran.map (GFORTRAN_1.0): Remove _gfortran_internal_free, _gfortran_internal_malloc and _gfortran_internal_malloc64. Add _gfortran_os_error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/move_alloc.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug fortran/30723] Freeing memory doesn't need to call a library function
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-14 20:34 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug c++/31923] New: g++ accepts a storage-class-specifier on a template explicit specialization
The following test program compiles without error or warning on g++ (versions 2.95.3, 3.4.5, 4.0.2, 4.1.0, 4.1.1, and 4.3-20070323): template static void F(); template<> static void F(); // Explicit specialization with storage class specifier The C++ standard seems to disallow this. From 7.1.1 - Storage class specifiers [dcl.stc], para 1: ... A storage-class-specifier shall not be specified in an explicit specialization (temp.expl.spec) or an explicit instantiation (temp.explicit) directive. I couldn't find an existing report of this, but may well have missed one. -- Summary: g++ accepts a storage-class-specifier on a template explicit specialization Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon_baldwin at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-14 20:51 ---
The patch below works and regtests OK. I am not convince that this is the
whole story and need to think about it for a day or two.
Paul
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (révision 124614)
--- gcc/fortran/trans-array.c (copie de travail)
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 4563,4569
limits will be the limits of the section.
A function may decide to repack the array to speed up access, but
we're not bothered about that here. */
! int dim, ndim;
tree parm;
tree parmtype;
tree stride;
--- 4563,4569
limits will be the limits of the section.
A function may decide to repack the array to speed up access, but
we're not bothered about that here. */
! int dim, ndim, stride_ne_one;
tree parm;
tree parmtype;
tree stride;
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 4613,4623
--- 4613,4628
else
base = NULL_TREE;
+ stride_ne_one = 0;
+
ndim = info->ref ? info->ref->u.ar.dimen : info->dimen;
for (n = 0; n < ndim; n++)
{
stride = gfc_conv_array_stride (desc, n);
+ if (!integer_onep (info->stride[dim]))
+ stride_ne_one = 1;
+
/* Work out the offset. */
if (info->ref
&& info->ref->u.ar.dimen_type[n] == DIMEN_ELEMENT)
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 4710,4715
--- 4715,4725
/* Set the offset. */
tmp = gfc_conv_descriptor_offset (parm);
gfc_add_modify_expr (&loop.pre, tmp, base);
+ }
+ else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)) && !stride_ne_one)
+ {
+ tmp = gfc_conv_descriptor_offset (parm);
+ gfc_add_modify_expr (&loop.pre, tmp, gfc_conv_array_offset (desc));
}
else
{
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-05-10 12:34:22 |2007-05-14 20:51:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug java/31890] Java Namespace error - javaprims.h out of sync
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-14 20:57 --- It is easy to forget to update this file, I'm sure that is what happened. This only matters if you have CNI code that uses one of these classes. So, it is definitely a problem, but generally not a very serious one. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-14 20:57:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31890
[Bug libfortran/31915] Failure with unf_io_convert_3.f90
--- Comment #2 from patchapp at dberlin dot org 2007-05-14 21:20 --- Subject: Bug number PR 31915 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00907.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31915
[Bug c++/29928] typeid of unknown bound array
--- Comment #5 from paolo at gcc dot gnu dot org 2007-05-14 21:21 --- Subject: Bug 29928 Author: paolo Date: Mon May 14 20:21:34 2007 New Revision: 124724 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124724 Log: /cp 2007-05-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29928 * rtti.c (get_tinfo_decl_dynamic, get_typeid): Try to complete the type only if is a class type (5.2.8/4). /testsuite 2007-05-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29928 * g++.dg/rtti/typeid5.C: New. Added: trunk/gcc/testsuite/g++.dg/rtti/typeid5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29928
[Bug c++/29928] typeid of unknown bound array
--- Comment #6 from pcarlini at suse dot de 2007-05-14 21:22 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29928
[Bug c/31924] New: gcc accepts invalid suffixes for decimal float constants
The change to the C preprocessor to recognize "df", "dd", and "dl" as suffixes for decimal floating point constants also allows "fd" and "ld"; a check for that assumed that the the letters are examined from left to right, but they are examined from right to left. There are no errors for the following: double a = 1.ld; double b = 1.fd; I'm testing a fix, but wanted a PR to reference for a patch to the 4.2 branch. -- Summary: gcc accepts invalid suffixes for decimal float constants Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c AssignedTo: janis at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31924
[Bug tree-optimization/31925] New: Internal compiler error in `store_bit_field', at expmed.c:277
Internal compiler error in `store_bit_field', at expmed.c:277. It seems that I've come across a case where compiling with gcc 2.95.4 (from the Debian package 2.95.4-22) using -O3 crashes, while compiling with no optimization does not crash. I will attach the .i file produced with -save-temps. I'm experiencing: $ gcc -O3 -c bm_kiss_double.cil.i ... ./bm_kiss_double.cil.c: In function `hcu_restore_frame_of___sgnl_v1': ./bm_kiss_double.cil.c:4273: Internal compiler error: ./bm_kiss_double.cil.c:4273: Internal compiler error in `store_bit_field', at expmed.c:277 Please submit a full bug report. See http://www.gnu.org/software/gcc/bugs.html> for instructions. I'm using the gcc 2.95.x series in a performance evaluation of various compilers. I did not try to reproduce with gcc 2.96 or gcc 2.97 (I don't see them being available for Debian). I confirmed that gcc 3.3.5 does not have this problem. -- Summary: Internal compiler error in `store_bit_field', at expmed.c:277 Product: gcc Version: 2.95.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkgnu at mkgnu dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31925] Internal compiler error in `store_bit_field', at expmed.c:277
--- Comment #1 from mkgnu at mkgnu dot net 2007-05-14 22:03 --- Created an attachment (id=13554) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13554&action=view) Source code that causes an internal compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31925] Internal compiler error in `store_bit_field', at expmed.c:277
--- Comment #2 from mkgnu at mkgnu dot net 2007-05-14 22:05 --- Output of gcc -v $ gcc -v -O3 -c bm_kiss_double.cil.i Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) /usr/lib/gcc-lib/i386-linux/2.95.4/cc1 bm_kiss_double.cil.i -quiet -O3 -version -o /tmp/ccvYzdxK.s GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease). ... ./bm_kiss_double.cil.c: In function `hcu_restore_frame_of___sgnl_v1': ./bm_kiss_double.cil.c:4273: Internal compiler error: ./bm_kiss_double.cil.c:4273: Internal compiler error in `store_bit_field', at expmed.c:277 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31925] Internal compiler error in `store_bit_field', at expmed.c:277
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-14 22:06 --- Well 2.95.4 is almost 6 years old and is no longer being maintained and has not for at least 5 years. Since you already mention this is fixed 3.3.5 I am going to close as being fixed there. Also note any release before 4.1 is no being maintained any more either so you should update to a newer release or have someone else support it for you. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31925
[Bug tree-optimization/31926] New: [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
svn Revision: 124725 - $ gcc -DHAVE_CONFIG_H -I. -I..-mno-cygwin -mdll -mthreads -DNDEBUG -UDEBUG -DWIN32 -D_WIN32 -DCONFIG_GPL -O4 -march=i686 -mtune=i686 -mssse3 -fomit-frame- pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -I../ -I../libavutil -I../../codecs -I../../imgFilters -I../../zlib -DHAVE_AV_C ONFIG_H -g -O2 -MT libavcodec_static_a-ffv1.o -MD -MP -MF .deps/libavcodec_stat ic_a-ffv1.Tpo -c -o libavcodec_static_a-ffv1.o ffv1.c -save-temps ffv1.c: In function 'encode_rgb_frame': ffv1.c:480: warning: assignment makes pointer from integer without a cast ffv1.c: In function 'decode_plane': ffv1.c:784: warning: initialization makes pointer from integer without a cast ffv1.c:784: warning: initialization makes pointer from integer without a cast ffv1.c: In function 'encode_plane': ffv1.c:438: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31926
[Bug tree-optimization/31926] [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
--- Comment #1 from jojelino at gmail dot com 2007-05-14 22:23 --- Created an attachment (id=13555) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13555&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31926
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #66 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #26 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug rtl-optimization/31360] [4.2 Regression] rtl loop invariant is broken
--- Comment #24 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug driver/14435] [4.0/4.1/4.2/4.3 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #23 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug c/12245] [4.0/4.1/4.2/4.3 regression] Uses lots of memory when compiling large initialized arrays
--- Comment #28 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug c++/23287] [4.0/4.1/4.2/4.3 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #16 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #67 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #37 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/29000] [4.2/4.3 regression] ICE on invalid use of template in statement-expr
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug middle-end/29256] [4.2/4.3 regression] loop performance regression
--- Comment #18 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug testsuite/28870] [4.2/4.3 Regression] configuring, over-riding timeout values in testsuite
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/29363] [4.2/4.3 regression] ICE throwing undeclared object
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug middle-end/29478] [4.2/4.3 Regression] optmization generates warning for casts
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
[Bug c++/31748] [4.2/4.3 regression] bad diagnostic for invalid private clause
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31748
[Bug target/25743] crosscompiler fails to build ada-rts for target platform.
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25743
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug testsuite/27376] treelang testsuite fails on cygwin
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27376
[Bug testsuite/27707] g++.dg/tree-ssa/ivopts-1.C fails
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug bootstrap/28949] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #25 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #16 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug debug/31899] [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-05-14 22:26 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
[Bug c++/28239] [4.2/4.3 regression] ICE in gimple_add_tmp_var, at gimplify.c:720
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28239
[Bug c/29129] [4.2/4.3 Regression] [DR needed] unnamed parameters using [*]
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug c++/28639] [4.2/4.3 regression] ICE trying to print error on invalid template parameter
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/29571] [4.2/4.3 regression] ICE with invalid static const member
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571
[Bug c++/30298] [4.2/4.3 regression] ICE with duplicate broken inheritance
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
[Bug c++/30299] [4.2/4.3 regression] ICE with broken template and inheritance
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug c++/30303] [4.2/4.3 regression] ICE with invalid constructor definition
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
[Bug tree-optimization/31130] [4.2/4.3 Regression] VRP no longer derives range for division after negation
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug c++/31131] [4.2/4.3 regression] ICE on invalid constructor definition
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/30535] [4.2/4.3 regression] ICE with invalid template operator
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30535
[Bug c++/22488] [4.1/4.2/4.3 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Comment #48 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug target/22553] [4.1/4.2/4.3 regression] ICE building libstdc++
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug c++/31747] [4.2/4.3 regression] ICE combining static and extern
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-05-14 22:27 --- Will not be fixed in 4.2.0; retargeting at 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
