[Bug c++/21038] Poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-04-15 06:04 --- Yes, it's a design flaw of C that parens and bracked are so overloaded that the compiler (or the human) can't tell if the problem is too many openers or not enough closers. Still, every little bit helps :-) Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:09 --- Sure. Actually the main file is a .F file. The tgz I'm about to attach contain the following files: - main.F : main file - guess.h params.h pinch_complet.h prec.h: included by the preprocessor - routines.h.ok : when renamed to routines.h, the program compiles fine - routines.h.bug: when renamed to routines.h, causes the bug to appear $ diff routines.* gives: 408c408 subroutine solution(n,xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) --- subroutine solution(xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) 438c438 parameter (n1=5,n2=5,ndims=10) --- parameter (n1=5,n2=5,n=1024,ndims=10) All I did was to add n as a new parameter of the solution() subroutine ; here the call to solution() is unchanged but adding a variable corresponding to n in the function call changes nothing, the bug still appears. Thanks again, cheers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:10 --- Created an attachment (id=8639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8639action=view) Source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug preprocessor/21039] New: libcpp incorrectly handles different headers with same name
This hits when compiling rrdtools, which creates a perl .xs module. It's and autoconf package, and hence has a config.h. perl also has a config.h used from it's headers (by doing a 'include config.h', so the one from the perl include dir is used correctly), which has a multiple include guard. Once the perl config.h is included the source goes on, and tries to include it's own config.h. There is no way anymore due to the bug. It tries to do this with '#include config.h', i.e. just searching the -I paths (which are setup correctly, so it could find it in ../config.h). But this doesn't work anymore (it did with 3.3.x), as somehow it seems that the place of config.h as it first was found is cached (the perl one), and then the ../config.h one isn't even tried. To demonstrate this I've put a tarball below. After unpacking, please do: % cd a % find -type f ./b/header.h ./b/inc-b.h ./c/inc.c ./header.h % cd c % gcc-4 -E -I .. -I ../b inc.c # 1 inc.c # 1 built-in # 1 command line # 1 inc.c # 1 ../b/inc-b.h 1 # 1 ../b/header.h 1 B # 1 ../b/inc-b.h 2 # 2 inc.c 2 Note how the two include directives in inc.c have no effect, _although_ -I .. is before -I ../b in the cmdline. gcc 3 does it correctly: % gcc-3 -E -I .. -I ../b inc.c | grep header.h # 1 inc.c # 1 built-in # 1 command line # 1 inc.c # 1 ../b/inc-b.h 1 # 1 ../b/header.h 1 B # 2 ../b/inc-b.h 2 # 2 inc.c 2 # 1 ../header.h 1 A # 3 inc.c 2 # 1 ../header.h 1 A # 4 inc.c 2 -- Summary: libcpp incorrectly handles different headers with same name Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug preprocessor/21039] libcpp incorrectly handles different headers with same name
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 --- Created an attachment (id=8640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640action=view) Tarball with the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug c++/21040] New: Segmentation fault on template/typedef typo
g++ reports: gpp_bug.cpp:10: internal compiler error: Segmentation fault, on
both Gentoo Linux (gcc 3.3.5) and Solaris (gcc 3.3.2).
Full output of g++ gpp_bug.cpp:
gpp_bug.cpp: In function `void func()':
gpp_bug.cpp:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugs.gentoo.org/ for instructions.
Preprocessed source stored into /tmp/ccIkMcGH.out file, please attach this to
your bugreport.
Output of g++ -v on the Linux system:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with: /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/info
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --enable-java-awt=gtk --enable-languages=c,c++,f77,java
Thread model: posix
gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Offending source code:
//BEGIN SOURCE CODE:
template class T
struct bar {
typedef T INNER_TYPE_DEF;
};
templateclass T
void func(){
typedef typename barT::INNER_TYPE_DEF LOCAL_TYPE_DEF;
LOCAL_TYPE_DEFT b;
}
int main(){ }
//END SOURCE CODE
Obviously LOCAL_TYPE_DEFT is nonsensical, I stumbled on this segfault as a
result of a typo.
--
Summary: Segmentation fault on template/typedef typo
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjanssen at cse dot unl dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21040
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From matz at suse dot de 2005-04-15 06:51 --- Perhaps due to the IPA infrastructure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-15 07:01 --- Subject: Re: GCC 3.4.3 wrongly reorders floating-point operations pinskia at gcc dot gnu dot org wrote: Note neg just flips a bit so it is correct anyways and there is no loss of precession. Can you please clarify what do you mean by correct? I believe that: 1) The produced code is incorrect, since operations cannot be reordered that way. Notice that the compiler cannot prove that the result is the same (in fact it is not, in general, as it depends on the rounding direction). 2) A piece of standard C that, when correctly compiled, performs a double to float conversion rounding up, when the rounding mode is downward, or rounding down, when the rounding mode is upward, no longer works when compiled with GCC. So the produced code is incorrect not only from a language-lawyer point of view: I am actually obtaining the wrong results. All the best, Roberto Bagnara -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/20812] contextual overload resolution failure for a member name found in two base classes
--- Additional Comments From SWElef at post dot sk 2005-04-15 07:30 ---
I was wrong. std:10.2/2 (member name lookup) says
[snip] If the resulting set of declarations are not all from sub-objects of
the same type, or the set has a nonstatic member and includes members from
distinct sub-objects, there is an ambiguity and the program is ill-formed.
[snip]
So the deduction may not succeed. On the other hand, IIRC it is also not
supposed to fail since the paragraph 14.8.2/2 that names all reasons for
deduction failure does not contain anything about this specific case. The
only reason that seems a little similar reads
Attempting to use a type in the qualifier portion of a qualified name that
names a type when that type does not contain the specified member, or if the
specified member is not a type where a type is required.
and in this case the named type _contains_ the specified member, it's just
ambiguous.
To expose the problem I wrote this new snippet:
struct B1{ typedef int T; };
struct B2{ typedef int T; };
struct D : B1, B2 { };
template typename X
typename X::T foo() { return X::T(); }
int main(){ fooD(); }
gcc reports error: no matching function for call to `foo()'. Comeau Online
says error: D::T is ambiguous which is very different (and IIRC correct).
May be this PR should be resolved as INVALID and another one should be written
with this snippet and a more appropriate subject.
Regards,
Vladimir Marko
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20812
[Bug tree-optimization/21004] [4.1 Regression] gcc.dg/builtins-53.c fails
--- Additional Comments From uros at kss-loka dot si 2005-04-15 07:42 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21004
[Bug target/21041] New: ICE: output_operand: Cannot decompose address
The below testcase is extracted from smpeg. It's C++. Compile it like
so:
% ./gcc/cc1plus -O2 -fPIC video.ii
video.cpp: In function 'int ParseMacroBlock(VidStream*)':
video.cpp:2205: internal compiler error: output_operand: Cannot decompose
address.
I wasn't able to make the functions much smaller than this (didn't try
reducing the headers, though).
--
Summary: ICE: output_operand: Cannot decompose address
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: uweigand at de dot ibm dot com
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: {s390,s390x}-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug target/21041] ICE: output_operand: Cannot decompose address
--- Additional Comments From matz at suse dot de 2005-04-15 08:19 --- Created an attachment (id=8641) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8641action=view) Preprocessed source for the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug target/21041] ICE: output_operand: Cannot decompose address
--- Additional Comments From matz at suse dot de 2005-04-15 08:20 --- Forgot to say, the preprocessed file is for s390x. On s390 the same happens, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-15 08:30 --- Reduced testcase is: $ cat pr21034.f subroutine solution(n) implicit none integer n real dte(n) save print *, dte end $ gfortran -c pr21034.f pr21034.f: In function solution: pr21034.f:4: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036 Please note that if print *,dte is replaced by any other statement using dte (such as dte(:) = 0 or call anothersub(dte)), the bug is the same. Removing this line, removing the save statement or make n a parameter lead to correct compilation. -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-15 08:30:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/15586] gfortran should support i18n in its compiler messages
-- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-03-04 04:03:01 |2005-04-15 08:39:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15586
[Bug libfortran/19216] list directed read with leading slash (NIST FM923)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-15 08:58 --- Patch: http://gcc.gnu.org/ml/fortran/2005-03/msg00562.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-15 10:21 ---
// smaller testcase, compile with -O2 -fPIC
struct vs {
int h, w, k, q;
short int dct_recon[8];
};
void bar (struct vs* v)
{
char *s;
short int *b;
int x, y, z, r, i, j;
for (i = 0; i 6; i++)
if (v-q)
{
if (i)
{
if (v-k v-h)
j = 1;
if (v-k v-w)
j += 1;
}
if (j)
{
*s++ = 0;
if (!z)
{
for (r = 0; r 8; r++)
{
b = (v-dct_recon[r]);
s[0] += b[0];
s[1] += b[1];
s[2] += b[2];
s[3] += b[3];
s[4] += b[4];
s[5] += b[5];
s[6] += b[6];
s[7] += b[7];
}
}
}
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-04-15 10:21:04
date||
Summary|ICE: output_operand: Cannot |[4.0 Regression] ICE:
|decompose address |output_operand: Cannot
||decompose address
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug c++/21042] New: Error while compiling jdk14
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
When installing jdk14 (java) through the ports tree with a simple make install
clean I came across this:
Compiling ../generated/adfiles/ad_i486_misc.cpp
{standard input}: Assembler messages:
{standard input}:104953: Warning: end of file not at end of a line; newline inse
rted
{standard input}:105865: Error: suffix or operands invalid for `mov'
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
gmake[3]: *** [ad_i486_misc.o] Error 1
gmake[3]: Leaving directory `/usr/ports/java/jdk14/work/control/build/bsd-i586/h
otspot-i586/tmp/bsd_i486_compiler2/product'
gmake[2]: *** [the_vm] Error 2
gmake[2]: Leaving directory `/usr/ports/java/jdk14/work/control/build/bsd-i586/h
otspot-i586/tmp/bsd_i486_compiler2/product'
gmake[1]: *** [product] Error 2
gmake[1]: Leaving directory `/usr/ports/java/jdk14/work/control/build/bsd-i586/h
otspot-i586/tmp'
gmake: *** [product] Error 2
*** Error code 2
Stop in /usr/ports/java/jdk14.
Sorry for any errors while making this bug report, my first time.
Thanks in advance.//Richard
--
Summary: Error while compiling jdk14
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samedii at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug c++/21043] New: Compilation error when trying to call method of a class contain by grand-mother with a template mother and class
g++ -v
Reading specs from
/.../Open-Sources/gcc/gcc-3.4.3/linux-x86/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /.../Open-Sources/gcc/gcc-3.4.3/src/configure
--prefix=/.../Open-Sources/gcc/gcc-3.4.3/linux-x86
Thread model: posix
gcc version 3.4.3
When i try to compile this code there is an error but it's compiling fine with
comeau online:
main.cc: In constructor `CT::C()':
main.cc:10: error: object missing in reference to `A::m_'
main.cc:25: error: from this location
But it's working fine with this-m_.p(); insteed of A::m_.p();
Following main.ii
# 1 main.cc
# 1 built-in
# 1 command line
# 1 main.cc
struct X
{
void p()
{ ; }
};
struct A{
X m_;
};
templatetypename T
struct B : public A
{
B():A(){Y=0;}
int Y;
};
templatetypename T
struct C : public BT
{
C():BT()
{
A::m_.p();
Z=0;
}
T Z;
};
int main()
{
Cint test;
return(1);
}
--
Summary: Compilation error when trying to call method of a class
contain by grand-mother with a template mother and
class
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maxime dot fiandino at imag dot fr
CC: gcc-bugs at gcc dot gnu dot org,maxime dot fiandino at
imag dot fr
GCC build triplet: g++ main.cc
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21043
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 11:25 --- Another thing is, that the warning shows up as alwazn:default gfortran -Wall -Dlinux -ffixed-form -I. -I../../include -o bounds.o -c bounds.F Warning: /tmp/cciShzeh.f:1: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:101: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:171: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:112: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated Warning: /tmp/cciShzeh.f:0: Line is being truncated I.e. it doesn't translate back to the original filename and looks confusing as line 0 is repeated endlessly. Of course this seems to be caused by the same problem. Testcase for the second problem attached - output is tmp gfortran -c t.f -Wall Warning: t.f:1: Line is being truncated Warning: t.f:0: Line is being truncated Warning: t.f:1: Line is being truncated Warning: t.f:0: Line is being truncated while it should be Warning: bounds.F:1: Line is being truncated Warning: ../../include/hh.inc:1: Line is being truncated Warning: bounds.F:12: Line is being truncated Warning: ../../include/hh.inc:1: Line is being truncated and possibly avoid giving duplicate warnings on files included multiple times. Of course I also like the warning being disabled for comment lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15 11:29 --- (In reply to comment #13) I believe that reshape needs the same/similar fix. Is ret-data = NULL guaranteed for temporaries? ret-data = NULL is what the front end generates when it doesn't know enough about the temporary. This is what I would have done but the question that I asked on the original PR is still unanswered - is it the caller or the callee who should be arranging the correct amount of memory for a temporary object? Ideally, it should be the caller, but that doesn't happen always at the moment. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 11:30 --- Oh btw, looking into fixing all this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug java/21044] New: Static class init optimization is broken
Pre tree-SSA, we did an optimization whereby we only initialized a class once
per method invocation. This optimization was disabled for some reason, and we
now call _Jv_InitClass multiple times.
The worst case is a simple function like this:
public static int Ack(int m, int n) {
return (m == 0) ? (n + 1) : ((n == 0) ? Ack(m-1, 1) :
Ack(m-1, Ack(m, n - 1)));
}
where Jv_InitClass is now called four times, leading to very poor performance.
--
Summary: Static class init optimization is broken
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug java/21044] Static class init optimization is broken
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-15 11:32 --- Created an attachment (id=8643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8643action=view) You must enter a description for the attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug c++/21043] Compilation error when trying to call method of a class contain by grand-mother with a template mother and class
--- Additional Comments From maxime dot fiandino at imag dot fr 2005-04-15 11:57 --- Hi, please note that for the same bahavior with the line, it's compiling: ((A*)(this))-m_.p(); -- What|Removed |Added GCC build triplet|g++ main.cc |i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21043
[Bug java/21045] New: Anonymous inner class constructor's exceptions can't be caught or thrown
When a method creates an instance of an anonymous inner class, it must catch or
declare any exceptions throwable by the inner class's constructor.
GCJ gives an error about this even though the method *does* handle or declare
it: (Will attach test cases...)
$ gcj -c FailThrow.java
FailThrow.java: In class 'FailThrow$1':
FailThrow.java: In constructor '(FailThrow)':
FailThrow.java:6: error: Exception java.lang.Exception must be caught, or it
must be declared in the throws clause of FailThrow$1.
InnerBase obj = new InnerBase() {};
^
1 error
Creating an instance of the base class, with the same constructor, works fine.
GCC built from CVS HEAD: gcj-4.0 (GCC) 4.1.0 20050415 (experimental)
./configure --prefix=/usr/local/gcj --program-suffix=-4.0
--enable-languages=c,c++,java
Running on Ubuntu Linux (Hoary Hedgehog).
--
Summary: Anonymous inner class constructor's exceptions can't be
caught or thrown
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brion at pobox dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
--- Additional Comments From brion at pobox dot com 2005-04-15 12:15 --- Created an attachment (id=8644) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8644action=view) Test case which wraps in a try-catch; fails to compile with GCJ Compiles just fine with javac from Sun JDK 1.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
--- Additional Comments From brion at pobox dot com 2005-04-15 12:16 --- Created an attachment (id=8645) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8645action=view) Test case using the base class; works Using a base class instead of an anonymous inner class derivitive, the exception is handled as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
--- Additional Comments From brion at pobox dot com 2005-04-15 12:17 --- Created an attachment (id=8646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8646action=view) Failing test case using a throws declaration instead of try-catch Again, fails to compile with GCJ. Fine with javac from Sun JDK 1.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
-- What|Removed |Added Summary|Static class init |[4.0/4.1 Regression] Static |optimization is broken |class init optimization is ||broken Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
--- Additional Comments From brion at pobox dot com 2005-04-15 12:20 --- Created an attachment (id=8647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8647action=view) Working test case with throws declaration Again, using the base class instead of an anonymous inner class the constructor's exception is handled correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug c++/21040] [3.3 regression] Segmentation fault on template/typedef typo
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-15 12:26 --- 3.3 branch breakage, almost surely WONTFIX. : Search converges between 2003-07-19-3.3 (#129) and 2003-07-20-3.3 (#130). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Known to fail||3.3.5 Known to work||3.3 3.4.4 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-04-15 12:26:53 date|| Summary|Segmentation fault on |[3.3 regression] |template/typedef typo |Segmentation fault on ||template/typedef typo http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21040
[Bug fortran/20925] Possible frontend bug: array constructor not expanded
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-15 12:37:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20925
[Bug tree-optimization/21046] New: move memory allocation out of a loop
Consider the following program fragment:
char *p;
int i;
for (i=0; i10; i++)
{
p = malloc(20);
foo(p,i);
free(p);
}
}
The loop could be simplified into
p = malloc(20);
for (i=0; i10; i++)
foo(p,i);
free(p);
This would reduce the overhead for memory allocation
considerably.
A more challenging case is to change
for (i=0; i10; i++)
{
p = malloc(2*i+2);
foo(p,i);
free(p);
}
into
p = malloc(20);
for (i=0; i10; i++)
foo(p,i);
free(p);
because the amount of memory allocated has an upper bound.
This is probably not a big win for straight C code. For languages
which generate temporary arrays at runtime, such as Fortran, it
could mean a significant reduction in memory management overhead.
--
Summary: move memory allocation out of a loop
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
[Bug fortran/20838] [4.1 regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:3606
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-15 12:44 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|i686-pc-linux-gnu | Keywords||diagnostic, ice-on-valid- ||code Known to fail||4.1.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-04-15 12:44:53 date|| Summary|error needed|[4.1 regression] ICE in ||gfc_conv_expr_descriptor, at ||fortran/trans-array.c:3606 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20838
[Bug c++/21043] Compilation error when trying to call method of a class contain by grand-mother with a template mother and class
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-15 12:59 --- Not a bug. This has to do with two-stage name-lookup, see last bullet in http://gcc.gnu.org/bugs.html#new34 and http://gcc.gnu.org/gcc-3.4/changes.html You could use this-m_.p(), this-A::m_.p(), BT::A::m_.p() -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21043
[Bug tree-optimization/21046] move memory allocation out of a loop
--- Additional Comments From giovannibajo at libero dot it 2005-04-15 13:04 --- I would think this is much more easily done in the frontend itself, which has a higher level representation so that it is much easier to hoist and reuse allocations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From giovannibajo at libero dot it 2005-04-15 13:10 --- Then, shouldn't your patch check -fwrapv somehow? And if Ada relies on wrap around, does it enable -fwrapv? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug preprocessor/21039] libcpp incorrectly handles different headers with same name
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:22 --- *** This bug has been marked as a duplicate of 20348 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:22 --- *** Bug 21039 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348
[Bug target/21042] Error while compiling jdk14
-- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug c++/21043] Compilation error when trying to call method of a class contain by grand-mother with a template mother and class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:30 --- Reopening to mark as ... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21043
[Bug c++/21043] Compilation error when trying to call method of a class contain by grand-mother with a template mother and class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:30 --- a dup of bug 21012. *** This bug has been marked as a duplicate of 21012 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21043
[Bug c++/21012] [4.0/4.1 regression] incorrect name lookup from nested struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:30 --- *** Bug 21043 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||maxime dot fiandino at imag ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21012
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
-- What|Removed |Added OtherBugsDependingO||18131 nThis|| Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug tree-optimization/21046] move memory allocation out of a loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:37 --- (In reply to comment #1) I would think this is much more easily done in the frontend itself, which has a higher level representation so that it is much easier to hoist and reuse allocations. Not really true anymore. Confirmed, related to PR 19831. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-04-15 13:37:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 13:39 --- (In reply to comment #7) Then, shouldn't your patch check -fwrapv somehow? And if Ada relies on wrap around, does it enable -fwrapv? Huh, the testcase is still defined C even though signed overflow is undefined since it is overflowing while in unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-15
13:48 ---
First: using stdio in a mixed Fortran/C is a small nightmare. For short term
purposes, I strongly suggest you use the GFORTRAN_STDIN_UNIT=-1 trick. That does
exactly what you want (that is, suggest that Fortran runtime library should not
mess with standard input).
Now, an intersting thing for wandering bug-fixers is that you can mix c and
fortran standard input if you disable preconnection and manually open
/proc/self/fd/0 to unit 5:
$ cat test.c
#include stdio.h
void foo_(void)
{
char buf[1024];
while(1) {
if(fgets(buf, 1024, stdin) == NULL) break;
printf(%s, buf);
}
}
$ gcc -c test.c
$ cat test1.f
external foo
character*70 c
read (*,'(A)') c
print *, c
print *, 'calling the C routine'
call foo
print *, 'end of the program'
end
$ cat test2.f
external foo
character*70 c
open (5, file='/proc/self/fd/0')
read (*,'(A)') c
print *, c
print *, 'calling the C routine'
call foo
print *, 'end of the program'
end
$ gfortran test1.f test.o
$ ./a.out test.c
#include stdio.h
calling the C routine
end of the program
$ gfortran test2.f test.o
$ GFORTRAN_STDIN_UNIT=-1 ./a.out test.c
#include stdio.h
calling the C routine
#include stdio.h
void foo_(void)
{
char buf[1024];
while(1) {
if(fgets(buf, 1024, stdin) == NULL) break;
printf(%s, buf);
}
}
end of the program
So, the question is: what is the difference between preconnection and manually
openning the unit? I did strace the two processes and I attach the diff of these
traces here (about 50 lines, easy to read). I think the solution to this problem
is here.
--
What|Removed |Added
Last reconfirmed|2005-04-10 10:38:34 |2005-04-15 13:48:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
Re: Interesting bug with imLib2/glut, or compiler error?
-BEGIN PGP SIGNED MESSAGE- ~ Ok, thanks for the explanation. I'm just surprized and disappointed that no error message was displayed, either durring the compile or the dlopen load. Why does the programmer have to remember every system function name and avoid them? Jay Andrew Pinski wrote: | | On Apr 14, 2005, at 10:32 PM, Jay Summet wrote: | | -BEGIN PGP SIGNED MESSAGE- | | I ran into an interesting bug when attempting to add imlib2 to a | program that | uses GLUT. The program would compile/link fine, but segfault when the | imlib_load_image() call was made. (initial call to imlib) | | The fix? | | change: | int time; | | to: | //int time; | | | time is a standard C function so if you declare a variable, well you just | overwrote it, this is not a GCC bug or even a imLib2/glut bug but | a bug in your program. | | -- Pinski | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBQl/HKrWkkhmZq4xxAQHOEgP9Gy5gMquKNCk1BYmMumbKjIYIW5X2/h6l EWnE5ER27VwwNL6WK8rGLmx4rsx4s6u3VeCl2Ezk44+YbQP0JahxJ1tA5/ENmHDe VWDsqNVciD0gzbCMPk+FLar/fg6rQXn5wsu1QutxkMNwPvrC8LMYkVIp+X8rwNje axL+nSsR1NY= =5peu -END PGP SIGNATURE-
[Bug tree-optimization/20936] [4.1 Regression] tree check: accessed operand 2 of view_convert_expr with 1 operands
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 14:06 --- Subject: Bug 20936 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 14:06:11 Modified files: gcc: ChangeLog tree-ssa-ccp.c Log message: PR tree-optimization/20936. * tree-ssa-ccp.c (visit_assignment): Fix a typo. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8303r2=2.8304 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gccr1=2.64r2=2.65 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20936
[Bug tree-optimization/20936] [4.1 Regression] tree check: accessed operand 2 of view_convert_expr with 1 operands
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 14:07 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20936
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 14:50 --- Created an attachment (id=8649) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8649action=view) proposed patch Proposed patch attached; it seems, error reporting interferes with warnings, though. Or error reporting causes line increment. Or whatever is going wrong. F.i we produce for SUBROUTINE foo(x,y) x = 4.3 + 1.2 END In file /tmp/t2.f:2 x = 4.3 1 Warning: Line truncated at (1) but for SUBROUTINE foo(x,y) x = 4.3 + 1.2 END In file /tmp/t2.f:2 x = 4.3 + 1 Error: Syntax error in expression at (1) I'm probably missing something obvious. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-15 14:52 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On 15 Apr 2005, Alexandre Oliva wrote: On Apr 12, 2005, Roger Sayle [EMAIL PROTECTED] wrote: I still like your fallbacks, that by trying harder we perform better optimization, The more I think about this, the more I have the impression that perhaps the fallbacks are not necessary. ... So I'm wondering if taking out all of the workarounds and going back to something like what is now in the 4.0 branch, except for the use of validate_change_maybe_volatile, wouldn't get us exactly what we want. ... Anyhow, in the meantime, could I check in the patch to fix Josh's asm-elf build failure? ... It would be nice to keep the hard failure in place for a bit longer, such that we stood a better chance of finding other situations that might require work arounds. Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline to resolve Josh's bootstrap failure. Sounds like you've already done the necessary testing, and I'll trust you on a suitable ChangeLog entry. I agree with your proposed game plan of keeping the hard failure in place temporarily, to discover whether there are any other fallback strategies that would be useful. Ultimately though, I don't think we should close PR20126 until a soft failure is implemented on mainline, like we've (Jakub has) done on the gcc-4_0-branch (such as the mainline code proposed in comment #30). Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-15 15:10 --- I didn't count columns, but why would you be surprised that x = 4.3 + is not a valid statement? At least this seems to be the compiler's complaint in your second example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug fortran/20954] gfortran - internal compiler error with -fdefault-integer-8
--- Additional Comments From dir at lanl dot gov 2005-04-15 15:12 --- This error is killing -fdefault-integer-8 - I hit it in almost every program I try to compile. Here is another example - [dranta:~/tests] dir% gfortran -fdefault-integer-8 -c d8test3.f d8test3.f: In function 'MAIN__': d8test3.f:5: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:152 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [dranta:~/tests] dir% cat d8test3.f program driver common /iodatac/ cmmnd(26) character*16 cmmnd character*80 hed write (hed,370) (cmmnd(i),i=1,8) stop 370 format (8a8) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20954
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 15:12 --- I'm surprised that the line truncation warning is omitted in the error case. Somewhere in the dark of the parser or error reporter someone advances to the next line without my notice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-15 15:15 --- The patch is ok. IIRC I actually tried the exact same thing, except that I used gfc_warning instead of gfc_warning_now (and indeed the latter makes a lot more sense). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-15 15:17 --- (In reply to comment #9) I'm surprised that the line truncation warning is omitted in the error case. Somewhere in the dark of the parser or error reporter someone advances to the next line without my notice. Yes, I had just figured out that there's a problem WRT to this. I guess that next_statement is not called if the statement is not finished, as is the case with the expression that is cut in half. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-15 15:27 --- Yes, this seems to be the case: when the statement matchers don't succeed, they skip to the next line via gfc_error_recovery, see the bottom of decode_statement. therefore the if (gfc_at_eol ()) you changed doesn't trigger. It looks like we should either have the statment matchers return a new statement type ST_ERROR, and not advance across the end-of-statement, or code similar to the code you added to next_statement is needed in gfc_error_recovery or thereabout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 15:30 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01726.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug middle-end/20371] Some corner cases of MS bitfields don't work
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-15 15:32 --- Created an attachment (id=8650) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8650action=view) Additional testcase This is another testlet snipped out of gcc-dg-struct-layout-1-t026-01. With the original patch, in struct S2503 field d overlaps field b, and hence the store goes into the wrong place. The idea of putting packed bit fields into rli-prev_field is bogus to start with. These fields are not necesasrily aligned like the underlying type, and packed fields are not supposed to place more restrictions on the placement of surrounding fields than ordinary non-bitfield types. E.g. a packed long long bitfield of size 8 is not expected to reserve more space than a char field, even if it is followed by a non-packed bitfield of a different type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20371
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-15 15:46 --- I just caught that you only sent the patch to gcc-patches@ Fortran patches should be sent to both gcc-patches@ and [EMAIL PROTECTED], few of the Fortran people are subscribed to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug tree-optimization/20963] [4.1 Regression] ICE tree check: expected value_handle, have addr_expr in value_exists_in_set_bitmap, at tree-ssa-pre.c:437
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-15 15:51 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20963
[Bug middle-end/21006] [4.1 Regression] g++.dg/other/static11.C fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 15:55 --- Also I can confirm that this is a middle-end problem. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21006
[Bug tree-optimization/20994] [4.1 regression] ICE with -ftree-vectorize
-- What|Removed |Added Known to fail||4.1.0 Known to work||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug debug/20940] [4.1 Regression] Option -ggdb3 stopped working
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 15:56 --- Fixed by reverting the patch which caused this. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20940
[Bug middle-end/20934] [4.1 Regression] Segmentation fault in gnat1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 15:56 --- Fixed by reverting the patch which caused this. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20934
[Bug middle-end/20719] [4.1 Regression] ICE in default_no_named_section, at varasm.c:4828
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 15:58 --- Fixed by a couple of patches. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20719
[Bug c/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 16:37 --- build_binary_op builds a binary tree node for r = (const void *) *q; Here are the details. (gdb) p resultcode $2 = GE_EXPR (gdb) call debug_tree(build_type) integer_type 0xb7cf5510 int public SI size integer_cst 0xb7ced408 type integer_type 0xb7cf5288 bit_size_type constant invariant 32 unit size integer_cst 0xb7ced198 type integer_type 0xb7cf521c unsigned int constant invariant 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0xb7ced3c0 -2147483648 max integer_cst 0xb7ced3d8 2147483647 pointer_to_this pointer_type 0xb7d029b4 (gdb) call debug_tree(op0) var_decl 0xb7d6a288 r type pointer_type 0xb7d6a21c type void_type 0xb7d6a1b0 void readonly VOID align 8 symtab 0 alias set -1 pointer_to_this pointer_type 0xb7d6a21c unsigned SI size integer_cst 0xb7ced408 constant invariant 32 unit size integer_cst 0xb7ced198 constant invariant 4 align 32 symtab 0 alias set -1 used unsigned SI file test.c line 6 size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 context function_decl 0xb7d6a06c foo initial nop_expr 0xb7cf22c0 (gdb) call debug_tree(op1) convert_expr 0xb7cf2320 type pointer_type 0xb7d6a21c type void_type 0xb7d6a1b0 void readonly VOID align 8 symtab 0 alias set -1 pointer_to_this pointer_type 0xb7d6a21c unsigned SI size integer_cst 0xb7ced408 constant invariant 32 unit size integer_cst 0xb7ced198 constant invariant 4 align 32 symtab 0 alias set -1 arg 0 indirect_ref 0xb7cf2300 type integer_type 0xb7cf557c unsigned int public unsigned SI size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0xb7ced480 0 max integer_cst 0xb7ced468 4294967295 pointer_to_this pointer_type 0xb7d63e58 arg 0 parm_decl 0xb7d63ec4 p type pointer_type 0xb7d63e58 used unsigned SI file test.c line 4 size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 context function_decl 0xb7d6a06c foo result pointer_type 0xb7d63e58 initial pointer_type 0xb7d63e58 arg-type pointer_type 0xb7d63e58 arg-type-as-written pointer_type 0xb7d63e58 chain parm_decl 0xb7d63f30 q Before the binary tree node is returned to the caller, build_binary_op calls fold to fold the newly built tree node. Since the tree node is a binary one, fold calls fold_binary. fold_binary strips what it considers to be useless type conversion. By the time we get to the case handling GE_EXPR, we have the following operands whose types do not match. (gdb) call debug_tree(arg0) var_decl 0xb7d6a288 r type pointer_type 0xb7d6a21c type void_type 0xb7d6a1b0 void readonly VOID align 8 symtab 0 alias set -1 pointer_to_this pointer_type 0xb7d6a21c unsigned SI size integer_cst 0xb7ced408 constant invariant 32 unit size integer_cst 0xb7ced198 constant invariant 4 align 32 symtab 0 alias set -1 used unsigned SI file test.c line 6 size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 context function_decl 0xb7d6a06c foo initial nop_expr 0xb7cf22c0 (gdb) call debug_tree(arg1) indirect_ref 0xb7cf2300 type integer_type 0xb7cf557c unsigned int public unsigned SI size integer_cst 0xb7ced408 constant invariant 32 unit size integer_cst 0xb7ced198 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0xb7ced480 0 max integer_cst 0xb7ced468 4294967295 pointer_to_this pointer_type 0xb7d63e58 arg 0 parm_decl 0xb7d63ec4 p type pointer_type 0xb7d63e58 type integer_type 0xb7cf557c unsigned int unsigned SI size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 symtab 0 alias set -1 used unsigned SI file test.c line 4 size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 context function_decl 0xb7d6a06c foo result pointer_type 0xb7d63e58 initial pointer_type 0xb7d63e58 arg-type pointer_type 0xb7d63e58 arg-type-as-written pointer_type 0xb7d63e58 chain parm_decl 0xb7d63f30 q type pointer_type 0xb7d63e58 unsigned SI file test.c line 4 size integer_cst 0xb7ced408 32 unit size integer_cst 0xb7ced198 4 align 32 context function_decl 0xb7d6a06c foo result pointer_type 0xb7d63e58 initial pointer_type 0xb7d63e58 arg-type pointer_type 0xb7d63e58 arg-type-as-written pointer_type 0xb7d63e58 Note that arg0 is of a pointer type, whereas arg1 is of an integer type. Roger, I don't think it's OK to create this kind of type mismatch. At the very least, that would complicate SSA optimizers. Thoughts? -- What|Removed |Added
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15 17:24 --- There's something rotten in the state of Denmark. I've slightly modified Paul's test program with my patch, and this is what I got: program test_spread implicit none integer, parameter :: N = 100 integer:: I integer, dimension(N) :: source integer, dimension(N,N) :: sink, check,c1,c2 source =(/(i, i=1,N)/) check = spread( source , 1 , N ) PRINT *,first 4x4 elements with DIM=1 write(*,'(1x,4I4)') check(1:4,1:4) check = spread( source , 2 , N ) PRINT *,first 4x4 elements with DIM=2 write(*,'(1x,4I4)') check(1:4,1:4) c1 = spread(source, 1, N) c2 = spread(source, 2, N) sink = spread( source , 1 , N ) * spread( source , 2 , N ) PRINT *,The product using temporaries write(*,'(1x,4I4)') sink(1:4,1:4) PRINT *,The product using fixed arrays sink = c1 * c2 write(*,'(1x,4I4)') sink(1:4,1:4) end program test_spread $ gfortran test_spread.f90 $ ./a.out first 4x4 elements with DIM=1 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 first 4x4 elements with DIM=2 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 The product using temporaries 100 0 0 0 200 0 0 0 300 0 0 0 400 0 0 0 The product using fixed arrays 1 2 3 4 2 4 6 8 3 6 9 12 4 8 12 16 I am not applying my patch for the moment. A segfault is better than a silently generated wrong result :-( Investigating further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug tree-optimization/21047] New: ASSERT_EXPR handling in fold never triggers.
According to tree.def, ASSERT_EXPR belongs to tcc_expression.
When fold gets a tree node that is tcc_expressions,
we do not get to the following switch statement.
switch (code)
{
case CONST_DECL:
return fold (DECL_INITIAL (t));
case ASSERT_EXPR:
So the ASSERT_EXPR case never triggers.
--
Summary: ASSERT_EXPR handling in fold never triggers.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21047
[Bug tree-optimization/21047] ASSERT_EXPR handling in fold never triggers.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 18:07 --- Confirmed, funny, I wonder why it was not noticed before, oh well. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-04-15 18:07:03 date|| Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21047
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 18:23 --- Ok, I'm looking into implementing your suggestion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From law at redhat dot com 2005-04-15 18:25 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs On Thu, 2005-04-14 at 14:02 -0300, Alexandre Oliva wrote: On Apr 4, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote: If the operands of a cond-expr used as an lvalue differ in cv qualification, the front-end adds nop_exprs to add cv qualifiers that the gimplifier drops when simplifying (T const)*v. The `' was added by gimplify_cond_expr. The problem is that gimplify_addr_expr gimplifies its operand in such a way that the nop_expr is dropped, and nothing puts it back in, so when we test that, in the indirect_ref case in gimplify_addr_expr, the types are compatible, the test fails because of the missing cv-qualifier in the pointed-to type. This patch fixes this. Ok to install if bootstrap and regtest on amd64-linux-gnu pass? Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline. I'm retesting on the branch, since I'm not entirely sure I actually tested it there. Approved for mainline. Mark has final call on the branch. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug tree-optimization/21048] New: use of poisoned ggc memory causes cpu2000 build failures
Current mainline gfortran fails to build four SPEC CPU2000 tests on powerpc64-linux using -m64 -O2 -ffast-math -funroll-loops. In a call to is_gimple_stmt it tries to dereference a pointer that the garbage collector has poisoned. This reduced test case (which can undoubtedly be made smaller) demonstrates the problem using --param gcc-min-heapsize=1 for powerpc-linux: subroutine foo implicit real*8 (a-h,o-z) real u(5,60,60,60) do i = 2, nx-1 x = dble(i-1) / (nx-1) do m = 1, 5 px = (1.0d+00 - x) * u(m,1,j,k) + x * u(m,nx,j,k) pz = (1.0d+00 - z) * u(m,i,j,l) + z * u(m,i,j,nz) u(m,i,j,k) = px + p + pz end do end do return end elm3b11% /opt/gcc-nightly/mline/bin/gfortran -c -m64 -O2 -ffast-math -funroll-loops --param ggc-min-heapsize=1 bug.f bug.f: In function foo: bug.f:1: internal compiler error: Segmentation fault elm3b11% /opt/gcc-nightly/mline/bin/gfortran -c -m32 -O2 -ffast-math --param ggc-min-heapsize=1 bug.f bug.f: In function foo: bug.f:1: internal compiler error: Segmentation fault The failure begins with this patch from dje: http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00598.html -- Summary: use of poisoned ggc memory causes cpu2000 build failures Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: dje at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 18:42 --- Subject: Bug 21031 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 18:42:38 Modified files: gcc: ChangeLog tree-ssa-forwprop.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr21031.c Log message: gcc/ PR tree-optimization/21031 * tree-ssa-forwprop.c (ssa_name_defined_by_comparison_p): New. (forward_propagate_into_cond_1): Call it. Forward propagate integer-integer casts into COND_EXPRs. testsuite/ PR tree-optimization/21031 * gcc.dg/tree-ssa/pr21031.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8313r2=2.8314 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-forwprop.c.diff?cvsroot=gccr1=2.13r2=2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5354r2=1.5355 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21031.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 18:44 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21031] Another missed forward propagation opportunity
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug target/20673] C PCH testsuite assembly comparison failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 19:14 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01761.html. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|pch |target Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-04-15 19:14:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 19:15 --- Effects only 4.0 now. -- What|Removed |Added Summary|C PCH testsuite assembly|[4.0 only] C PCH testsuite |comparison failure |assembly comparison failure Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug testsuite/20767] gcc.dg/tree-ssa/ssa-pre-8.c scan-tree-dump-times Eliminated: 4 1 fails on 64-bit systems
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20767
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 19:23 --- Subject: Bug 20673 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 19:23:47 Modified files: gcc: ChangeLog Log message: Add PR target/20673 to previous changelog. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8315r2=2.8316 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 19:25 --- Subject: Bug 20673 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-15 19:25:04 Modified files: gcc/config/sparc: sparc.h Log message: PR target/20673 * config/sparc/sparc.h (sparc_hard_reg_printed): Mark as GTY(()). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.273.8.2r2=1.273.8.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-15 19:26 --- This should be fixed both in mainline and the 4.0 branch -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
-- What|Removed |Added Target Milestone|4.0.1 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
-- What|Removed |Added Target Milestone|4.0.1 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug middle-end/21049] New: [4.1 Regression] ICE with -fdump-tree-all and fortran
Try to compile the following code with -fdump-tree-all and you will get a seg fault: subroutine foo return end -- Summary: [4.1 Regression] ICE with -fdump-tree-all and fortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21049
[Bug middle-end/21049] [4.1 Regression] ICE with -fdump-tree-all and fortran
-- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21049
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15 19:39 --- Spread putting its result into temporary arrays does indeed do something strange, even if the front end is providing the space. This is with an unpatched spread_generic.c: program test_spread implicit none integer, parameter :: N = 4 integer:: I integer, dimension(N) :: source integer, dimension(N,N) :: temp, sink source = (/(i,i=1,4)/) temp = spread (source, 1, N ) sink = spread( source , 1 , N ) + 0 print *,'On the fly:' print '(1x,4I12)',sink print *,'Using temporary array:' sink = temp + 0 print '(1x,4I12)',sink end program test_spread $ gfortran t1.f90 $ ./a.out On the fly: 1 437457152 386863616 22 2 134537768 12 1075739744 3 116774548 1073850628 4 1073772283 1073853733 134513615 Using temporary array: 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|use of poisoned ggc memory |[4.1 Regression] use of |causes cpu2000 build|poisoned ggc memory causes |failures|cpu2000 build failures Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug target/20810] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-15 19:57 ---
// reduced testcase, compile with -O2 -mthumb
extern void foo (void);
struct bitset
{
int a[4];
void set(int pos, bool val = true)
{
if (val)
a[pos/32] = 1;
}
bitset flip()
{
return *this;
}
bitset operator~()
{
return bitset(*this).flip();
}
bool operator != (const bitset x)
{
for (int i = 0; i 4; ++i)
if (a[i] != x.a[i])
return false;
return true;
}
bool test(int position)
{
if (position = 64)
foo ();
return a[position / 32] != 0;
}
};
int main( int argc, char *argv[] )
{
unsigned int i, j;
bitset b1, b2;
b2 = ~b1;
if (b2 != ~b1);
for (i = j = 0; i 65; i++)
{
b2.set (j);
if (i != b1.test(j))
foo ();
j++;
}
b2 = ~b2;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Keywords||ice-on-valid-code
Known to fail||3.4.4
Last reconfirmed|-00-00 00:00:00 |2005-04-15 19:57:02
date||
Summary|[ARM thumb] ICE with C++|ICE in
|bitsets in thumb mode |reload_cse_simplify_operands
||, at postreload.c:391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20810
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 19:58 --- Here is a testcase which removes the use of uninitialized variables and still crashes: subroutine foo(z, nx,j,k,l,nz) implicit real*8 (a-h,o-z) real u(5,60,60,60) do i = 2, nx-1 x = dble(i) / (nx) do m = 1, 5 u(m,i,j,k) = x * u(m,1,j,k) + z * u(m,i,j,nz) + u(m,i,j,l) end do end do return end -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-15 19:58:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug fortran/14569] should not warn about truncated comment lines
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-15 20:01 --- It works by not advancing to the next line in gfc_error_recovery. Final patch at http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01768.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14569
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15 20:06 --- Subject: Bug 18495 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-15 20:06:17 Modified files: libgfortran: ChangeLog libgfortran/intrinsics: spread_generic.c gcc/testsuite : ChangeLog gcc/testsuite/gfortran.fortran-torture/execute: intrinsic_spread.f90 Log message: 2005-04-15 Thomas Koenig [EMAIL PROTECTED] PR libfortran/18495 * intrinsics/spread_generic.c (spread): Remove const from return array descriptor. New variables: rrank (rank of return array), rs (for calculating the size of the return array), srank (rank of the source array). Generate runtime error if the dim= argument is larger than the rank of the return array. Generate runtime error if the needed rank of the return array is larger than 7. If ret-data is null, populate the return array descriptor and initialize the variables for the actual operation. Otherwise, set ret-dim[0].stride to one if it is zero. Change second, independent use of variable dim to srank. 2005-04-15 Thomas Koenig [EMAIL PROTECTED] PR libfortran/18495 * gfortran.fortran-torture/execute/intrinsic_spread.f90: Test callee-allocated version of return array with a write statement. Test spread with a temporary with another write statement. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.193r2=1.194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/spread_generic.c.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5355r2=1.5356 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_spread.f90.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 20:12 --- Here is a reduced testcase with the additional option of --param ggc-min-expand=0 which forces collection all the time: subroutine foo( nx,j,dble) implicit none integer i,j,nx real*8 x,dble(nx) real u(5,60,60) do i = 2, nx-1 x = dble(i) / (nx) u(2,i,j) = x end do return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug middle-end/20061] Certain flags generate warnings when they should not.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15 20:23 --- I just ran into this today, as -fdump-tree-all is broken for a different reason. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20061
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15 20:30 --- Fixed in 4.1 with this patch: http://gcc.gnu.org/ml/fortran/2005-04/msg00459.html Waiting for 4.0 to reopen. -- What|Removed |Added Summary|Intrinisc function SPREAD is|[4.0 only] Intrinisc |broken |function SPREAD is broken Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug target/21050] New: [4.1 Regression] vect-none.c ICE
FAIL: gcc.dg/vect/vect-none.c (test for excess errors) appeared on ia64-hpux (both -milp32 and -mlp64) on mainline between 20050413 and 20050414. gcc-testresults shows it also present on ia64-linux and I would guess it is the same failure. vect-none.c: In function 'foo': vect-none.c:181: error: unrecognizable insn: (insn 423 422 424 11 (set (reg:V2SF 660) (lt:V2SF (const_vector:V2SF [ (const_double:SF 0.0 [0x0.0p+0]) (const_double:SF 0.0 [0x0.0p+0]) ]) (reg:V2SF 510 [ vect_var_.70 ]))) -1 (insn_list:REG_DEP_TRUE 422 (nil)) (nil)) vect-none.c:181: internal compiler error: in extract_insn, at recog.c:2082 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.1 Regression] vect-none.c ICE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
[Bug target/21050] [4.1 Regression] vect-none.c ICE
-- What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
