[Bug middle-end/29256] [4.2/4.3 regression] loop performance regression
--- Comment #22 from ghazi at gcc dot gnu dot org 2008-01-12 08:35 --- Thanks, testsuite patch posted here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00530.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:36
---
Subject: Bug 34722
Author: jvdelisle
Date: Sat Jan 12 08:35:25 2008
New Revision: 131487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131487
Log:
2008-01-12 Jerry DeLisle [EMAIL PROTECTED]
PR fortran/34722
* match.c (gfc_match_name): Don't error if leading character is a '(',
just return MATCH_NO.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug fortran/34432] integer(kind=init_expression) function is rejected
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:37
---
Subject: Bug 34432
Author: jvdelisle
Date: Sat Jan 12 08:36:52 2008
New Revision: 131488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131488
Log:
2008-01-12 Jerry DeLisle [EMAIL PROTECTED]
PR fortran/34432
* match.c (gfc_match_name): Don't error if leading character is a '(',
just return MATCH_NO.
Modified:
trunk/gcc/fortran/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34432
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:39 --- Ignore comment #13, copy paste error on commit for 34432. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug c++/34747] __attribute__((aligned(x)))+__alignof != correct behaviour
--- Comment #2 from andry at inbox dot ru 2008-01-12 08:42 ---
(In reply to comment #1)
I think this is really just PR 10179 which was fixed for 4.3.0.
Could you test it on 4.3?
I tried to make trunk, but stopped with error:
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2605: error: cannot compute suffix of object files: cannot compile
could you run my test on g++ 4.3 to see is that all ok?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747
[Bug fortran/34432] integer(kind=init_expression) function is rejected
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:48 --- Subject: Bug 34432 Author: jvdelisle Date: Sat Jan 12 08:47:27 2008 New Revision: 131489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131489 Log: 2008-01-12 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34432 * gfortran.dg/parens_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parens_7.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34432
[Bug fortran/34432] integer(kind=init_expression) function is rejected
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:49 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34432
[Bug c/34748] New: cc1 fails with Not a directory on trivial file
In a gcc invocation, cc1 fails with a Not a directory error when compiling a
trivial file if there is a file (not a directory) named lib in the parent to
the working directory.
To recreate it:
bash-3.2# mkdir temp
bash-3.2# cd temp
bash-3.2# mkdir temp1
bash-3.2# touch lib
bash-3.2# cd temp1
bash-3.2# catutl1.cEOF
void fun1(){}
EOF
bash-3.2# gcc -c utl1.c
cc1: error: ../lib/gcc/i686-pc-linux-gnu/4.2.1/include: Not a directory
cc1: error:
../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include: Not a
directory
gcc was built as follows:
../gcc-4.2.1/configure --prefix=/usr\
--libexecdir=/usr/lib --enable-shared --enable-threads=posix\
--enable-__cxa_atexit --enable-languages=c,c++\
--disable-bootstrap
make
make install
when run verbosely, gcc produces the following output:
bash-3.2# gcc -c -v utl1.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 4.2.1
/usr/lib/gcc/i686-pc-linux-gnu/4.2.1/cc1 -quiet -v -iprefix
../lib/gcc/i686-pc-linux-gnu/4.2.1/ utl1.c -quiet -dumpbase utl1.c
-mtune=generic -auxbase utl1 -version -o /tmp/ccsAiCrL.s
cc1: error: ../lib/gcc/i686-pc-linux-gnu/4.2.1/include: Not a directory
cc1: error:
../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include: Not a
directory
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.2.1/include
/usr/include
End of search list.
GNU C version 4.2.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.1.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=97102
--
Summary: cc1 fails with Not a directory on trivial file
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: af804 at bfn dot org
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=34748
[Bug fortran/32489] Endless loop when compiling
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-12 09:19 --- I forgot to say that the patch in #5 fixed this PR, but you can add to the list of regressions: [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_result_6.f90 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_result_6.f90:63: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
[Bug fortran/32489] Endless loop when compiling
--- Comment #8 from pault at gcc dot gnu dot org 2008-01-12 09:43 --- (In reply to comment #4) Dominique, Indeed - I found all those regressions when I got up this morning. However, the patch indicates which way to go. The compiler is repeatedly trying to expand an array that it cannot. I need to write an equivalent to gfc_is_constant_expr that will test if the array can be expanded or not. Thanks! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49 --- I think symbolic substitutions should be only done if the resulting stmt can be simplified to a constant. Now for VRP my long-term plan is to get rid of symbolic ranges altogether to make it cheaper and easier to keep value-range information across passes. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #16 from pinskia at gmail dot com 2008-01-12 12:26 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code --- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49 --- I think symbolic substitutions should be only done if the resulting stmt can be simplified to a constant. Now for VRP my long-term plan is to get rid of symbolic ranges altogether to make it cheaper and easier to keep value-range information across passes. Actually I think it is wrong to get rid of symbolic ranges. I have filed a couple of bugs about adding more symbol ranges with respect of VRP. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-12 12:29 --- Can you point me to those? I still think we should separate VRP of constant and symbolic ranges. For symbolic stuff we eventually want to utilize a theorem prover. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-12 12:36 --- (In reply to comment #17) Can you point me to those? PR25643 and PR25145 . Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-12 12:38 --- ifcombine fixes this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-12 12:44 --- This is not fixed for me with gcc version 4.3.0 20071110 (experimental) [trunk revision 130075] (GCC) or with Sun Jan 6 02:53:41 UTC 2008 (revision 131347) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-12 12:48
---
There should be no call to _gfortran_runtime_error_at and I still get one:
# i_2 = PHI 1(3), i_27(6)
if (i_2 size.1_4)
goto bb 5;
else
goto bb 6;
bb 5:
# i_32 = PHI i_2(4) _gfortran_runtime_error_at (At line 7 of file
t.f90[1]{lb: 1 sz: 1}, Array reference out of bounds for array \'v\', upper
bound of dimension 1 exceeded (%ld %ld)[1]{lb: 1 sz: 1}, i_32, size.1_4);
Yes one call to _gfortran_runtime_error_at is removed but that is the lower
bound one.
Even the C testcase has the same issue.
we still get a call to abort:
L4:
call_abort
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-01-12 12:49 --- Compile with -fbounds-checking -O2, and notice that there is still That should be just -fbounds-check . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-12 12:42 --- Actually VRP1 catches both the fortran and the C testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25145] missed VRP opportunity
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-12 13:05 --- The first testcase in the original report is fixed by comparison canonicalization, even if a temporary is used (forwprop re-instantiates the canonicalized comparison). The testcase in comment #1 is fixed by FRE simplifying binary expressions: Value numbering D.1178_3 stmt = D.1178_3 = k_2 i_1(D); RHS k_2 i_1(D) simplified to 1 has constants 0 So none of the testcases is useful to show missing optimizations in VRP anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
[Bug middle-end/34744] Memory leaks in compiler with empty program
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-12 13:16 --- I know what this bug is but i do not actually know how to find it. The bug is caused by someone abandoning a basic block without going thur the api to properly delete it or merge it into another block. any suggestions on how to track this down would be appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34744
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-01-12 13:34 --- Fixed on mainline (at least checking number of references from cross compiler). -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug ada/15610] Invalid program not detected, generic formal parameter hides declared item
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-01-12 13:52 --- By adding one line to the test case, we can see the bug reappears: procedure Test_244942 is function f1 return integer is begin return 1; end f1; generic with function foo return integer; package pak1 is type color is (foo); type color2 is (foo); -- this line was added end pak1; package new_pak1 is new pak1(f1); i: integer := new_pak1.foo; -- ERROR: integer vs. color begin null; end Test_244942; gnatmake test_244942 gcc-4.1 -c test_244942.adb gnatbind -x test_244942.ali gnatlink test_244942.ali gcc-4.2 -c test_244942.adb gnatbind -x test_244942.ali gnatlink test_244942.ali -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||3.4.0 4.1.2 4.2.2 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15610
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-01-12 13:55 --- I can definitely commit the patch to silence the (IMO valid) diagnostics. However, why programs are using always_inline and extern inline combination at all? Just extern inline should be enough. /* For GNU C extern inline functions disregard inline limits. */ if (DECL_EXTERNAL (fndecl) DECL_DECLARED_INLINE_P (fndecl)) DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1; So perhaps just modifying glibc headers to not do both would do the trick? I agree that solving this problem correctly via two functions (not only bodies, but simply two declarations) is probably bit tricky for stage3. We however have related PR34609 and PR31529 demonstrating same problem in different context. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug other/28023] documentation error max-inline-recursive-depth
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-01-12 14:03 --- Subject: Bug 28023 Author: hubicka Date: Sat Jan 12 14:02:06 2008 New Revision: 131492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131492 Log: PR other/28023 * invoke.texi (max-inline-recursive-depth): Fix default value. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28023
[Bug c++/34749] New: Incorrect warning when applying dllimport to friend function
I was playing with some code and got a warning about dllimport in some
headers. I looked around a bit and came up with this test case.
The warning seems to imply that dllimport is ignored on bar(), but looking at
the output the call to bar() is indeed mangled with __imp prefix.
I'm using MinGW g++ 4.2.1-dw2.
## begin df.cpp
__attribute__((dllimport)) int bar();
class Foo
{
private:
int foo();
friend __attribute__((dllimport)) int bar();
};
int Foo::foo()
{
return bar();
}
## end df.cpp
D: g++ -S df.cpp
df.cpp:7: warning: 'int bar()' redeclared without dllimport attribute:
previous dllimport ignored
D: g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc
--enable-libgomp --host =mingw32 --build=mingw32 --target=mingw32
--program-suffix=-dw2 --with-arch=i486 --with-tune=generic
--disable-werror --prefix=/mingw --with-local-prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c+
+,fortran,objc,obj-c++,ad a --disable-win32-registry
--disable-sjlj-exceptions --enable-libstdcxx-debug --
enable-cxx-flags=-fno-function-sections -fno-data-sections
--enable-version-spec ific-runtime-libs --disable-bootstrap Thread
model: win32 gcc version 4.2.1-dw2 (mingw32-2)
--
Summary: Incorrect warning when applying dllimport to friend
function
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sldev327 at softmagi dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-12 14:23
---
Simplified C testcase (omitting the parts that are optimized). We cannot
figure out the number of iterations of this loop:
void f(int n, float *v)
{
int i;
if (n = 0)
return;
else
{
i = 1;
do {
if (i n) __builtin_abort ();
v[i] = 0.;
i++;
} while (i = n);
}
}
Note that for this simplified testcase DOM figures out the redundant test,
but not if you use i != n as the exit test, as for n == 1 the assert
will trigger. If you look at the fortran IL, it does instead
} while (i++ != n);
which would be ok again, but is still not optimized.
Testcase:
extern void link_error (void);
int i, n;
int main()
{
if (i n)
return;
if (i != n)
if (i = n)
link_error ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug other/28023] documentation error max-inline-recursive-depth
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-01-12 14:04 --- Fixed in mainline. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28023
[Bug libfortran/34746] [4.3 Regression] wrong formats in libgfortran's runtime_error
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 14:04 --- ../../../gcc-4.3-work/libgfortran/generated/maxval_i4.c:322: warning: format '%d' expects type 'int', but argument 2 has type 'long int' ../../../gcc-4.3-work/libgfortran/generated/minloc0_8_r8.c:86: warning: format '%d' expects type 'int', but argument 3 has type 'index_type' s/%d/%ld%/g and prefixing the argument with (long) should be enough, shouldn't it? (Whether the cast is needed, can depended on the platform, e.g., 32 vs 64 bit pointers; better add to many than too few casts.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-12 14:04:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34746
[Bug rtl-optimization/21676] [4.0/4.1/4.2/4.3 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #13 from steven at gcc dot gnu dot org 2008-01-12 14:34 --- Re. comment #7, Assignment to sum should be moved before if... This is called code hoisting, and it is not performed in GCC except with -Os. See bug 24001, bug 33315, and other reports about the same issue in Bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug fortran/34665] Cannot pass scalar to array argument 'a'
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-12 14:36 --- A related but slightly separate issue is illustrated by the following example. The argument of the second call to FOO is an expression; however, expressions involving assumed-size arrays are evil. This is detected for assignments: Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'a' at (1), but not for actual arguments. (Note: Procedure calls are in so far different as passing the assumed-size array itself it valid.) subroutine one(a) external foo integer :: a(*) integer :: b call foo(a) ! ok call foo((a)) ! Wrong call foo(a+1) ! Wrong b = a+1 ! diagnosed as being invalid end subroutine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34665
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #9 from rguenther at suse dot de 2008-01-12 15:13 --- Subject: Re: [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining On Sat, 12 Jan 2008, hubicka at gcc dot gnu dot org wrote: --- Comment #8 from hubicka at gcc dot gnu dot org 2008-01-12 13:55 --- I can definitely commit the patch to silence the (IMO valid) diagnostics. However, why programs are using always_inline and extern inline combination at all? Just extern inline should be enough. /* For GNU C extern inline functions disregard inline limits. */ if (DECL_EXTERNAL (fndecl) DECL_DECLARED_INLINE_P (fndecl)) DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1; So perhaps just modifying glibc headers to not do both would do the trick? I agree that solving this problem correctly via two functions (not only bodies, but simply two declarations) is probably bit tricky for stage3. We however have related PR34609 and PR31529 demonstrating same problem in different context. Can you give it a try? If it looks reasonably safe I would certainly prefer such a solution. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug libfortran/34746] [4.3 Regression] wrong formats in libgfortran's runtime_error
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-12 15:14 --- (In reply to comment #1) s/%d/%ld%/g and prefixing the argument with (long) should be enough, shouldn't it? That's what I will do. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2008-01-12 14:04:27 |2008-01-12 15:14:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34746
[Bug c++/34750] New: ICE in fold_convert, at fold-const.c:1955
compiling gccfolderr.cc like this: g++-4.1 -g -Wall -Wdeprecated -Wno-cast-qual -pipe -O2 -ftracer \ -finline-functions -fno-keep-static-consts gccfolderr.cc yields: gccfolderr.cc: In function voidunnamed::test_array(): gccfolderr.cc:34571: internal compiler error: in fold_convert, at \ fold-const.c:1955 compiling it without options still results in an ICE: g++-4.1 gccfolderr.cc albeit a different one: gccfolderr.cc:34571: internal compiler error: in cp_expr_size, at \ cp/cp-objcp-common.c:101 gcc version details (etch x86): $ g++-4.1 --version g++-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) compressed preprocessor file follows. -- Summary: ICE in fold_convert, at fold-const.c:1955 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: timj at gtk dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug c++/34750] ICE in fold_convert, at fold-const.c:1955
--- Comment #1 from timj at gtk dot org 2008-01-12 15:34 --- Created an attachment (id=14929) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14929action=view) compressed C++ preprocessor output the preprocessed code was spewed out by gcc in the middle of development, it is not meant to do anything sensible. line directives have been stripped and it was compressed with bzip2 to avoid inflating bugzilla with 3MB preprocessor blobs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug target/34571] [4.3 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-12 16:22 --- Patch of comment #3 looks good to me. -- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-12 16:34 --- i personally think that this patch in #8 is not the right way to go. unless there is a compelling argument that initializing this is going to have some negative performance effect, we should properly initialize this datastructure as we do (or at least try to do) for every other data structure in the compiler. While the current code that peter has written is correct, it is quite tricky. This compiler has way too much tricky code, which only adds to the long term maintainance cost of the compiler. the patch in 8 is not acceptable because it requires that the compiler be built in a particular way to avoid the valgrind errors. The last thing that you want to have to do if you have a heisenbug is to rebuild your compiler in a way that will change the layout and alignment of things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #10 from bonzini at gnu dot org 2008-01-12 16:52 --- an alternative is to prepare a suppression file for valgrind, and distribute it with gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-12 17:05 --- until someone has the slightest bit of evidence that initializing the datastructure is costly, this is just a waste of time. peter wrote the code this way to be cute, not because there was any reason to believe that getting a zerod data structure was going to be noticeable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug c++/34750] ICE in fold_convert, at fold-const.c:1955
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 17:47 --- Can you please retain line directives so we can bring this up to current development versions? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug libgcj/33764] [4.2/4.3 regression] gij is built as 32-bit binary when building multilib gcc
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-12 17:53 --- P2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33764
[Bug c++/34751] New: [4.3 regression] ICE with pointer to member and variadic templates
The following (IMHO valid) code snippet triggers an ICE on mainline:
struct A {};
templateint, typename T = A, int T::*...p = 0 struct B {};
B0 b;
bug.cc:5: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:8934
Please submit a full bug report, [etc.]
A similar testcase just segfaults:
struct A {};
templatetypename T = A, int T::*...p = 0 struct B {};
B b;
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
--
Summary: [4.3 regression] ICE with pointer to member and variadic
templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-12 17:56 --- I'm downgrading this to P2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/34752] New: [4.3 regression] pointer to member rejected in variadic template
The following (IMHO valid) code snippet is rejected on mainline:
struct A {};
templateint*...p struct B1; // OK
templateint*... struct B2; // OK
templateint A::*...p struct B3; // OK
templateint A::*... struct B4; // error
bug.cc:6: error: expected '' before '...' token
--
Summary: [4.3 regression] pointer to member rejected in variadic
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug c++/34752] [4.3 regression] pointer to member rejected in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug fortran/34741] Bounds-check of array-pointer == [ constructor ]
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 18:01 --- gfortran does only create a check for ptr itself and not for ptr - constructor; the created check looks (with some temporary variables added) as follows: if (prt.lbound ptr.lbound || ptr.lbound ptr.ubound) (It were be also great if this would not be written by gfortran as it is rather useless; though the middle end will remove it using -O.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34741
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:02 --- Also ICEs cc1plus with plain -O2 the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #13 from pcarlini at suse dot de 2008-01-12 18:06 --- Anyway... The issue, after all, seems pretty academic to me, for the simple reason that, per your report, the only known example of a named locale showing '\0' as thousands separator is bg_BG, and most likely the data isn't even ok, per your glibc report. Therefore, unless the data turns out to be ok and the glibc people tell us, contrary to our understanding, that a \0 must be interpreted differently, there is really nothing to do. Let's suspend the PR, in the meantime. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-12 18:06:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug c++/34753] New: [4.3 regression] ICE with invalid template parameter in variadic template
The following invalid code snippet triggers an ICE on mainline:
templatetypename... T struct A
{
templateT struct B {};
};
Aint::B0 b;
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In instantiation of 'Aint':
bug.cc:6: instantiated from here
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The ICE appeared between 2007-11-30 and 2007-12-11.
--
Summary: [4.3 regression] ICE with invalid template parameter in
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34750] ICE in fold_convert, at fold-const.c:1955
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-12 18:09 --- Note this may be invalid code, g++ 3.4 reports: gccfolderr.cc: In constructor `Rapicorn0752::Model::AutoValue::AutoValue(const Rapicorn0752::Model::Array)': gccfolderr.cc:34571: error: invalid use of undefined type `struct Rapicorn0752::Model::Array' gccfolderr.cc:34450: error: forward declaration of `struct Rapicorn0752::Model::Array' gccfolderr.cc:34571: error: initializing argument 2 of `Rapicorn0752::Model::AnyValue::AnyValue(Rapicorn0752::Model::Type::Storage, V) [with V = Rapicorn0752::Model::Array]' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #6 from pcarlini at suse dot de 2008-01-12 18:12 --- Thanks for the suggestion, Benjamin. Actually, I don't think we can much better *without* concepts... Anyway, was thinking that the ordering check is already impossible to do in other circumstances, like real (single pass) input iterators, therefore, we have probably to live with that and reconsider the issue together with concepts, as you are saying. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug c++/34754] New: [4.3 regression] ICE with invalid function arguments in variadic template
The following invalid code snippet triggers an ICE on mainline:
templatetemplateint class... T struct A
{
void foo(T0);
void bar(T0);
};
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'templateint anonymous class T'
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in bind_template_template_parm, at cp/tree.c:1242
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
--
Summary: [4.3 regression] ICE with invalid function arguments in
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34754] [4.3 regression] ICE with invalid function arguments in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34755] New: [4.3 regression] ICE with invalid argument in variadic template function
The following invalid code snippet triggers an ICE on mainline:
templatetypename struct A {};
templatetemplatetypename class... T void foo(Tint) {}
template void fooA(Aint);
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'templateclass class T'
bug.cc:5: internal compiler error: tree check: expected template_type_parm or
template_template_parm or bound_template_template_parm, have error_mark in
fn_type_unification, at cp/pt.c:11623
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
Maybe related to PR 34754.
--
Summary: [4.3 regression] ICE with invalid argument in variadic
template function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34755
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #7 from pcarlini at suse dot de 2008-01-12 18:23 --- Eh! Interestingly, conceptgcc explicitly enforces the concept that the two value types must equal! Exactly the case that is covered but my almost-ready patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-12 18:23
---
Here's a similar testcase with a function instead of a nested class
that also segfaults:
templatetypename... T struct A
{
templateT A();
};
Aint a;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34750] [4.1/4.2 Regression] ICE in fold_convert, at fold-const.c:1955
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:24 ---
Reduced testcase:
namespace std {
templatetypename _CharT
class basic_string {
public:
basic_string(const _CharT* __s);
};
typedef basic_stringchar string;
}
typedef signed long long int int64;
typedef std::string String;
class Array;
class Type {
public:
enum Storage { NUM = 'n', FLOAT = 'f', STRING = 's',
OBJECT = 'O', STRING_VECTOR = 'v', ARRAY = 'A' };
};
class BaseValue {
protected:
explicit BaseValue (Type::Storage value_type);
};
class AnyValue : public BaseValue {
public:
templatetypename V
explicit AnyValue (Type::Storage strg, V value)
: BaseValue (strg) { }
};
class AutoValue : public AnyValue {
public:
AutoValue (const String string)
: AnyValue (Type::STRING, string) { }
AutoValue (const Array array)
: AnyValue (Type::ARRAY, array) { }
};
class Array {
public:
Array (const Array other);
explicit Array ();
Array operator= (const Array other);
void push_tail (const AutoValue value) {}
};
void test_array ()
{
Array a;
const char *x[][8] = {};
for (int64 i = 0; i sizeof (x) / sizeof (x[0]); i++)
{
Array b;
for (int64 j = 0; j sizeof (x[0]) / sizeof (x[0][0]); j++)
b.push_tail (String (x[i][j]));
a.push_tail (b);
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.0.4 4.1.3 4.2.3
Known to work||3.4.6 4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-01-12 18:24:22
date||
Summary|ICE in fold_convert, at |[4.1/4.2 Regression] ICE in
|fold-const.c:1955 |fold_convert, at fold-
||const.c:1955
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug c++/34756] New: [4.3 regression] ICE with broken specialization of variadic template
The following invalid code snippet triggers an ICE on mainline:
templatetypename... class A {};
templateint class A {};
templatetypename T, typename...U struct AT,U... : AU...
{
A() {}
};
Aint a;
bug.cc:3: error: template parameters not used in partial specialization:
bug.cc:3: error: 'anonymous'
bug.cc: In constructor 'AT, U ...::A() [with T = int, U = ]':
bug.cc:10: instantiated from here
bug.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:489
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with broken specialization of
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34756
[Bug c++/34757] New: [4.3 regression] ICE with invalid parameters in variadic template
The following invalid code snippet triggers an ICE on mainline:
templatetypename int M, int N, int (*... p)[N] struct A {};
A0 a;
bug.cc:1: error: expected nested-name-specifier before 'int'
bug.cc:1: error: two or more data types in declaration of 'M'
bug.cc:1: error: no default argument for 'N'
bug.cc:1: error: no default argument for 'p'
bug.cc:3: error: 'type error' is not a valid type for a template constant
parameter
bug.cc:3: error: template argument 2 is invalid
bug.cc:3: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:8934
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
Maybe related to PR34751.
--
Summary: [4.3 regression] ICE with invalid parameters in variadic
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34757] [4.3 regression] ICE with invalid parameters in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34758] New: [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
The diagnostic for the following invalid code snippet degraded in GCC 3.4.0:
===
struct A
{
A (const A = A());
};
===
Since GCC 3.4.0 we get:
bug.cc:3: error: the default argument for parameter 0 of 'A::A(const A)' has
not yet been parsed
But before we got the much clearer diagnostic (although it was just a warning):
bug.cc:3: warning: circular dependency in default args of `A::A(const A)'
In addition, the counting of the parameters should start with 1.
--
Summary: [4.1/4.2/4.3 regression] Bad diagnostic for circular
dependency in constructor default argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/33964] [4.3 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)
--- Comment #5 from andreasmeier80 at gmx dot de 2008-01-12 19:06 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00482.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
--- Comment #6 from andreasmeier80 at gmx dot de 2008-01-12 19:08 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00491.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
--- Comment #7 from andreasmeier80 at gmx dot de 2008-01-12 19:09 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00149.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-12 19:13 ---
Danny, maybe you mis-understood. We try to generate *VH.98, but VH.98 is
indeed
not in avail_out[19], but created for example as
exp_gen[4] := { x_7(D) (VH.72) , D.1661_4 (VH.98) , *VH.74 (VH.75) , a.1_6
(VH.76) , *VH.72 (VH.77) , (unsigned int) VH.77 (VH.78) , VH.76 + VH.78 (VH.79)
, *VH.79 (VH.80) , (unsigned int) VH.80 (VH.81) , VH.81 * 2 (VH.82) , VH.75 +
VH.82 (VH.83) , *VH.83 (VH.84) , (int) VH.84 (VH.85) , VH.85 8192 (VH.86) }
tmp_gen[4] := { D.1661_4 (VH.98) , D.1662_5 (VH.75) , a.1_6 (VH.76) , D.1664_8
(VH.77) , D.1665_9 (VH.78) , D.1666_10 (VH.79) , D.1667_11 (VH.80) , D.1668_12
(VH.81) , D.1669_13 (VH.82) , D.1670_14 (VH.83) , D.1671_15 (VH.84) , D.1672_16
(VH.85) , D.1673_17 (VH.86) }
exp_gen[7] := { D.1661_4 (VH.98) , D.1667_34 (VH.97) , *VH.98 (VH.99) ,
(unsigned int) VH.97 (VH.100) , VH.100 * 2 (VH.101) , VH.99 + VH.101 (VH.102) ,
*VH.102 (VH.103) , (int) VH.103 (VH.104) , VH.104 8192 (VH.105) }
tmp_gen[7] := { D.1661_35 (VH.98) , D.1662_36 (VH.99) , D.1668_42 (VH.100) ,
D.1669_43 (VH.101) , D.1670_44 (VH.102) , D.1671_45 (VH.103) , D.1672_46
(VH.104) , D.1673_47 (VH.105) }
exp_gen[9] := { D.1661_4 (VH.98) , D.1667_53 (VH.109) , *VH.98 (VH.110) ,
(unsigned int) VH.109 (VH.111) , VH.111 * 2 (VH.112) , VH.110 + VH.112 (VH.113)
, *VH.113 (VH.114) , (int) VH.114 (VH.115) , VH.115 8192 (VH.116) }
tmp_gen[9] := { D.1661_54 (VH.98) , D.1662_55 (VH.110) , D.1668_61 (VH.111) ,
D.1669_62 (VH.112) , D.1670_63 (VH.113) , D.1671_64 (VH.114) , D.1672_65
(VH.115) , D.1673_66 (VH.116) }
exp_gen[10] := { D.1661_4 (VH.98) , D.1667_53 (VH.109) , *VH.98 (VH.110) ,
(unsigned int) VH.109 (VH.111) , VH.111 * 2 (VH.112) , VH.110 + VH.112 (VH.113)
, *VH.113 (VH.114) , (int) VH.114 (VH.115) , VH.115 8192 (VH.116) }
But all these expressions for VH.98 are plain SSA_NAMEs.
So we can in fact not do insertion of *VH.98 in two of the preds of BB. It
looks like we do not do verification for that anywhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug c++/34750] [4.1/4.2 Regression] ICE in fold_convert, at fold-const.c:1955
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-01-12 19:23
---
Even further reduced testcase:
=
struct A
{
templatetypename T A(T);
};
class C;
struct B : A
{
B(const C c) : A(c) {}
};
struct C
{
C(const C);
C();
C operator= (const C);
};
B b = C();
=
bug.cc: In constructor 'B::B(const C)':
bug.cc:10: internal compiler error: in cp_expr_size, at
cp/cp-objcp-common.c:100
Please submit a full bug report, [etc.]
This is really invalid code (C is used before it is defined).
The bug was fixed on mainline between 2007-10-13 and 2007-11-13.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||ice-on-invalid-code,
||monitored
Known to fail|4.0.4 4.1.3 4.2.3 |4.0.4 4.1.2 4.1.3 4.2.0
||4.2.1 4.2.2 4.2.3
Known to work|3.4.6 4.3.0 |3.4.6 4.0.0 4.0.3 4.1.0
||4.1.1 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug rtl-optimization/31396] Inline code performance much worse than out-of-line
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-12 19:00 --- Created an attachment (id=14930) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14930action=view) tentative fix I am testing the attached patch. It is obvious that we should use profile here. The PR is most likely regression to 2.95 that used to multiply n_refs by 3 inside loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug c++/34752] pointer to member rejected in variadic template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 19:41 --- How is this a regression? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] pointer to |pointer to member rejected |member rejected in variadic |in variadic template |template| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:42 --- ICE-after-error for non c++0x mode. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:42:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 19:43 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:43:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34754] [4.3 regression] ICE with invalid function arguments in variadic template
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:44:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34757] [4.3 regression] ICE with invalid parameters in variadic template
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:44:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:46 --- Confirmed. With the better diagnostic we had accepts-invalid, so lowering priority as regression status is not exactly clear. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:46:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-12 19:48 --- Maybe sth for steven, as he was asking for bugs to look at... ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||stevenb dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #6 from dberlin at gcc dot gnu dot org 2008-01-12 19:33 --- Subject: Re: [4.3 Regression] ICE in find_or_generate_expression On 12 Jan 2008 19:13:56 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-12 19:13 --- Danny, maybe you mis-understood. We try to generate *VH.98, but VH.98 is indeed not in avail_out[19], but created for example as So we can in fact not do insertion of *VH.98 in two of the preds of BB. It looks like we do not do verification for that anywhere? Sure we do. It should never be ANTIC if it is not possible to regenerate the expression. Anything else is a bug in ANTIC calculation or initial exp_gen/tmp_gen/etc set construction. valid_in_sets ensures that SSA_NAME's are either AVAIL_OUT[1], or available in our current ANTIC set. ANTIC propagation subtracts TMP_GEN from ANTIC, which should ensure that values do not get hoisted above the point that creates them. [1] I honestly don't remember why valid_in_sets ensures that SSA_NAME's are AVAIL_OUT when bare. That seems wrong to me. The correct condition is whether they are in our current ANTIC set, just like it does for more complex expressions. I do not remember when or why this got changed, but it seems like a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug fortran/34759] New: Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
With gfortran 4.3.0 20080109 I get an incorrect error message Error: 'source' argument of 'shape' intrinsic at (1) must not be an assumed size array with the following little test case subroutine j_assumed_size(A,N) dimension A(10,11,12,*) k = shape(A(:,:,:,N)) l = shape(A(:,:,:,3)) end I believe assumed size arrays are allowed provided the last subscript is specified. Dick Hendrickson -- Summary: Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug fortran/34760] New: PRIVATE variable not allowed as STAT variable in ALLOCATE
With gfortran 4.3.0 20080109 I get the error message ALLOCATE (RLA1(NF10), STAT = ISTAT) 1 Error: STAT expression at (1) must be a variable With the following program. MODULE TESTS INTEGER, PRIVATE :: ISTAT !this one FAILS ! INTEGER :: ISTAT !this one works ! PRIVATE :: ISTAT !this one FAILS CONTAINS SUBROUTINE AD0001 REAL RLA1(:) ALLOCATABLE RLA1 ISTAT = -314 ALLOCATE (RLA1(NF10), STAT = ISTAT) END SUBROUTINE END MODULE In the real module there are several subroutines that do similar allocates and they do not generate the error. It looks like it is only the first use of ISTAT in an allocate that triggers the message. Dick Hendrickson -- Summary: PRIVATE variable not allowed as STAT variable in ALLOCATE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug fortran/34761] New: ICE in TRANSFER with pointer mold
Extracted from PR 34741 :
$ cat bar.f90
character, pointer :: ptr(:)
allocate(ptr(1))
ptr = transfer('a',ptr)
end
$ gfortran bar.f90
f951: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
Using host libthread_db library /lib/i686/cmov/libthread_db.so.1.
(gdb) r bar.f90
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 bar.f90
Program received signal SIGFPE, Arithmetic exception.
0x080b1855 in gfc_simplify_transfer (source=0x89b5478, mold=0x89b54e8,
size=0x0) at ../../../gcc/trunk/gcc/fortran/simplify.c:4140
4140 result_length = source_size / result_elt_size;
(gdb) p result_elt_size
$1 = 0
(gdb) bt
#0 0x080b1855 in gfc_simplify_transfer (source=0x89b5478, mold=0x89b54e8,
size=0x0) at ../../../gcc/trunk/gcc/fortran/simplify.c:4140
#1 0x08071189 in do_simplify (specific=0x899faa0, e=0x89b5408)
at ../../../gcc/trunk/gcc/fortran/intrinsic.c:3191
#2 0x08071f87 in gfc_intrinsic_func_interface (expr=0x89b5408, error_flag=1)
at ../../../gcc/trunk/gcc/fortran/intrinsic.c:3450
#3 0x080a5e3f in gfc_resolve_expr (e=0x89b5408)
at ../../../gcc/trunk/gcc/fortran/resolve.c:1629
#4 0x080a932e in resolve_code (code=0x89b5628, ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:6104
#5 0x080ab29c in resolve_codes (ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:8996
#6 0x080ab2d3 in gfc_resolve (ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:9015
#7 0x0809c4b8 in gfc_parse_file ()
at ../../../gcc/trunk/gcc/fortran/parse.c:3380
#8 0x080c54a5 in gfc_be_parse_file (set_yydebug=0)
at ../../../gcc/trunk/gcc/fortran/f95-lang.c:260
#9 0x0836954c in toplev_main (argc=2, argv=0xbfecab94)
at ../../../gcc/trunk/gcc/toplev.c:1042
#10 0x0811161f in main (argc=Cannot access memory at address 0x0
) at ../../../gcc/trunk/gcc/main.c:35
--
Summary: ICE in TRANSFER with pointer mold
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 31237
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug c/34762] New: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
While building RPM on hppa with gcc-4.2, build fails with the captioned error. Somewhat reduced testcase attached. Builds fine with -O1 or without -fPIC, or with older compilers. ffmpeg and squashfs also fail to build with a similar error (not always built with -fPIC) -- Summary: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-linux GCC host triplet: hppa-linux GCC target triplet: hppa-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug fortran/34761] ICE in TRANSFER with pointer mold
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 20:53 --- Works for me. I think it is a duplicate of the very recently fixed PR 34537. Can you check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug c/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #1 from tausq at debian dot org 2008-01-12 20:54 --- Created an attachment (id=14931) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14931action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug fortran/34760] PRIVATE variable not allowed as STAT variable in ALLOCATE
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-01-12 20:59:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug fortran/34763] New: bare END not allowed in an interface block in a module procedure
With gfortran 4.3.0 20080109 I get the error message n_interface.f:7.12: END 1 Error: END SUBROUTINE statement expected at (1) with the following program module n contains subroutine n_interface INTERFACE SUBROUTINE NGSXDY(TLS1,TLS2) REAL :: TLS1,TLS2 END END INTERFACE end end module If the n_interface is an external procedure it works fine. A bare END statement is allowed in interface blocks. I'd guess you are misapplying the constraint after R1224 to things inside of interface blocks. But NGSXDY isn't a module subroutine. You'll probably need a similar fix for functions in interface blocks, although I haven't tried that. Dick Hendrickson -- Summary: bare END not allowed in an interface block in a module procedure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #12 from bonzini at gnu dot org 2008-01-12 21:09 --- well if you can enjoy O(n) initialization (and O(1) clearing as in Peter's code), you had better rewrite the code completely to query an item with one (not two) memory accesses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug fortran/34665] Cannot pass scalar to array argument 'a'
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-12 21:13 --- One has to be careful not to to get the same problem as with SHAPE in PR 34759, i.e. passing a rank-2 array A(:,:,5) defined as rank-3 assumed-shape array A(:,:,*). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34665
[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:13 --- Confirm, though your reduced test case is invalid (the variables k and l need to be arrays. Corrected test case: subroutine j_assumed_size(A,N) dimension A(10,11,12,*), k(3), l(3) k = shape(A(:,:,:,N)) l = shape(A(:,:,:,3)) end SOURCE may be of any type. It may be a scalar or an array. It shall not be an unallocated allocatable or a pointer that is not associated. It shall not be an assumed-size array. The shall-nots do not apply for the rank-3 arrays A(:,:,:,N) and A(:,:,:,3). Actually, this could be a wider problem, which is not only limited to check.c's gfc_check_shape. (For actual/dummy argument checking, I added a note to PR 34665.) Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug fortran/34763] bare END not allowed in an interface block in a module procedure
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:23 --- Confirm. (Though you missed subroutine for end subroutine n_interface in your example.) The Fortran 2003 references are: C1243 (R1230) FUNCTION shall appear in the end-function-stmt of an internal or module function. and C1248 (R1234) SUBROUTINE shall appear in the end-subroutine-stmt of an internal or module subroutine. Seemingly, the contained_procedure() check in decl.c, called by gfc_match_end, does not work properly. Thanks for report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-01-12 21:23:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-12 21:24:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug fortran/34761] ICE in TRANSFER with pointer mold
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-12 21:53 --- (In reply to comment #1) Works for me. I think it is a duplicate of the very recently fixed PR 34537. Can you check? Bootstrapping right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug target/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 21:44 --- Probably a dup of PR32889. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug objc/28050] [4.1/4.2/4.3 regression] ICE on invalid initializer
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-12 22:03 --- Created an attachment (id=14932) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14932action=view) Robustify C/objC parser Tested (objc only) on cygwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
[Bug c/34764] New: A Flame About 64-bit Pointers
(Please note this is a copy paste from Donald E. Knuth's homepage: http://www-cs-faculty.stanford.edu/~uno/news.html - Given who he is, I think the issue should receive a bit of love) It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache. The gcc manpage advertises an option -mlong32 that presumably does what I want. Namely, it should compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it should also know that my program is going to live inside a 32-bit virtual address space. Unfortunately, the gcc I got with Ubuntu 7.10 says that -mlong32 is an unknown option. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc. Please, somebody, make that possible. -- Summary: A Flame About 64-bit Pointers Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pgquiles at elpauer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 22:15 --- Well first Knuth did read full the documentation because -mlong32 is only for MIPS. Second don't post flames. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #13 from dcb314 at hotmail dot com 2008-01-12 22:17 --- (In reply to comment #9) i personally think that this patch in #8 is not the right way to go. unless there is a compelling argument that initializing this is going to have some negative performance effect, we should properly initialize this datastructure as we do (or at least try to do) for every other data structure in the compiler. While the current code that peter has written is correct, it is quite tricky. This compiler has way too much tricky code, which only adds to the long term maintainance cost of the compiler. Well said Sir. If the tricky code bought a 10% speedup, I'd advocate it. No one seems to have measured and documented how much it really saves. Unmeasured claims really don't count. Machines double in performance every few years, hence the prudent engineer codes in the default case for clarity, not performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 22:27 --- bla -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
